Minolta di-5510 scanning

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • copyman
    Owner / Technician

    Site Contributor
    2,500+ Posts
    • Sep 2005
    • 4524

    #1

    Minolta di-5510 scanning

    My customer recently changed email providers and cannot scan now. The IT guy I use to set up copiers said they will no longer be able to scan to emails. It has to be done with FTP at this point. Something about this fiery being so old it cannot do SMTP authentication with the new providers. I find it hard to believe there is not a "work around" for this? Anyone know how I can get this to work using SMTP scan to email? They do not have an exchange serve. Hope I explained this right, I don't do the IT work just the repairs.
    Thanks for the help
  • aesthetics1
    Trusted Tech

    100+ Posts
    • May 2010
    • 148

    #2
    The IT guy is 100% correct. You will not get this machine to scan using SMTP authentication, or non-default ports, or SSL, or any other modern e-mail technology.

    This machine is really unreliable for scanning to FTP without a DNS server (for host names). In most environments where a lot of the users are using laptop computers (taking the machine on/off the network, can't rely on static IP addresses [or alternatively cannot set up DHCP reservations due to 'less than robust' network equipment]) this will be an absolute nightmare.

    My personal recommendation is to advise an upgrade to a more recent model, such as the bizhub 600, 601 series, or even the Bizhub 500 or Bizhub 423 series. All of these machines support modern email technologies.

    Your only real 'work-around' which will be extremely hokey would be to set up a small PC in their office running something like ArGoSoft mail server, where you can create an in-house e-mail server that would just receive from the copier and forward to in-house addresses.

    In summary, it's not worth the trouble if you haven't set something like this up before.

    I recommend advising an upgrade to a recent model.

    Comment

    • mdavin
      Technician
      • Aug 2008
      • 70

      #3
      Try using the ISP's SMTP server...ping the host name to get the IP address. Most ISP will let you send an email on port 25 with out restrictions on a business accounts. There are restrictions if the account is a residential account.

      Comment

      • aesthetics1
        Trusted Tech

        100+ Posts
        • May 2010
        • 148

        #4
        Originally posted by mdavin
        Try using the ISP's SMTP server...ping the host name to get the IP address. Most ISP will let you send an email on port 25 with out restrictions on a business accounts. There are restrictions if the account is a residential account.
        This used to be the case, but recently the ISPs have swapped over to SMTP Authentication due to spammer accounts using their servers.

        It might be worth looking into, but I would imagine that they use SMTP Auth.

        Comment

        • mdavin
          Technician
          • Aug 2008
          • 70

          #5
          Maybe it depends on the area but I have yet to run into one that blocks it in S.Fl, ATT/bellsouth and comcast will block it on residential but not on a business line and a T1 provider should not care what you do its your pipeline. If they changed this I would have a long list of service calls for scan-to-email not working....as a matter of fact I set up 3 yesterday one Comcast 2 AT&T.

          Comment

          • Morton & Associates
            Junior Member
            • Aug 2009
            • 6

            #6
            First off - the technology used behind email communications has not changed, nor has it been "modernized" in general, for well over 10 years, if not 20.

            The question is can your machine be configured to support all three types of SMTP "authentication?"

            I'd bet the answer is yes, because, SMTP authentication hasn't changed for a very long time.

            Sometimes your email service provider will require that a user name and password accompany your emails before it is allowed to be sent out. However, sometimes they don't.

            The problem is that if they don't, but your machine thinks that they do, your machine might not provide you with any useful information to investigate the problem further.

            The roadblock I ran into, and very likely the problem you are experiencing is:

            The outgoing email SMTP "authentication" settings in your machine differ from the authentication requirement implemented by your email service provider.

            Email service providers can choose 1 of 3 types of authentication methodologies:

            1. SMTP with authentication required
            2. SMTP without authentication required
            3. POP3 before SMTP

            If:

            1. Your email account (hosted at your email service provider's external server) chose to utilize #2 SMTP without authentication required...

            but

            2. Your machine is configured to send emails with #1 "SMTP with authentication required" (as was my case) your machine will still attempt to transmit the email to your email service provider. In the process, it will provide a user name and password, but will fail as shown below:

            Trying xxx.xxx.xxx.xxx...
            Connected to xxx.xxx.xxx.xxx.
            Escape character is '^]'.
            220 OurDomainName.com
            ESMTP
            EHLO OURDOMAINNAME.COM
            250-ourdomainname.com
            250-PIPELINING
            250-SIZE 10485760
            250 8BITMIME
            AUTH LOGIN
            502 unimplemented (#5.5.1)

            However, you might not receive any error message at all, or a cryptic one like "SERVER CONNECTION ERROR"

            Using Outlook to troubleshoot the problem will not give you the answers you need. In fact, Outlook hides important detail that would clue you into what the problem is.

            Outlook won't fail to send a test email if your email service provider responds with "502 unimplemented (#5.5.1)" but your machine probably does.

            Instead, Outlook will re-attempt to send your email without authentication, but it won't tell you. It doesn't tell you there was an initial error because that wouldn't be "user friendly." So even if you told outlook that your email service provider requires authentication to send outgoing emails - and even if you provided a user name and password in Outlook, it won't prevent your email from being delivered.

            The lack of identical response between Outlook and your machine might mislead your IT person to believe that your machine lacks the "modern" feature. Only problem is that "modern" Bizhubs have the same "problem."

            Note that Outlook behaves differently then your Machine. While your machine will fail with an error message that lacks useful a description, Outlook will simply try a different authentication methodology without displaying any error messages, even though there was one: "502 unimplemented (#5.5.1)."

            Quick solution - Find out what authentication methodology your email service provider has implemented by process of elimination.

            First change the Machine's settings:

            2. Does not require SMTP authentication.

            If that fails, then try:

            1. SMTP with authentication required

            Then finally:

            3. POP3 before SMTP

            If none of the 3 above work, you have another problem.

            I've discussed everything you need to know up to this point. However - I have provided the following in case the methodology I used could be helpful in certain situations.

            ####The remainder of this post describes additional troubleshooting steps you can take to sort this out.####

            ***How to tell which of the three authentication methodologies your email service provider has implemented***

            Since your machine won't provide you with useful information to determine the cause of the problem, you have to find out why the failure is taking place yourself.

            You can use Wireshark and Telnet to determine what the cause of the problem is.

            Wireshark is a network packet sniffer. It is able to listen to the network traffic being sent by the Machine - that is - if you are able to run it on a computer that will pick up traffic sent by the Machine:

            A.) If you are on a network that utilizes a switch - you have to run Wireshark in between the scanner and a machine you tell the scanner to send its requests to directly. Of course that means the computer you run Wireshark on has to 1.) be capable of acting as an email server and 2.) configured to receive an email from the Machine.

            b.) If your network utilizes a hub - you can run Wireshark from any desk.

            Once you start Wireshark, look for transmissions between your Machine and the computer acting as the email server. Right click on one of them and select "Follow TCP stream."

            A successful transmission of "SMTP with Authentication" appears as follows:

            220 hostname.OurDomainName.com ESMTP Postfix
            EHLO 192.168.0.1
            250-hostname.OurDomainName.com
            250-PIPELINING
            250-SIZE 10240000
            250-VRFY
            250-ETRN
            250-STARTTLS
            250-AUTH LOGIN PLAIN
            250-AUTH=LOGIN PLAIN
            250-ENHANCEDSTATUSCODES
            250-8BITMIME
            250 DSN
            AUTH LOGIN
            334 xxxxxxxxxxxx
            xxxxx=
            334 xxxxxxxxx
            xxxxxxxx=
            235 2.7.0 Authentication successful

            Now that you know what a (successful scan to email) looks like - you can compare how your ISP's email account responds to the commands being sent to it by the Machine to it with telnet.

            The next step involves connecting to your outside email service provider's SMTP port with telnet and replicating the actions the Machine will take when it sends a scan to your email service provider.

            You can either use the same IP number as your outside email service provider's registered domain name or simply the domain name.

            Open a terminal and type: telnet YourDomainName.com 25

            You should have the following responses:

            Trying xxx.xxx.xxx.xxx...
            Connected to xxx.xxx.xxx.xxx.
            Escape character is '^]'.
            220 YourDomainName.com
            ESMTP
            EHLO YOURDOMAINNAME.COM
            250-yourdomainname.com
            250-PIPELINING
            250-SIZE 10485760
            250 8BITMIME

            At this point, type: AUTH LOGIN

            If, when you log in, the response is OK - you know that your email service provider requires authentication to send outgoing emails. Change your setting accordingly, if that is the case.

            If the response to "AUTH LOGIN" is "502 unimplemented (#5.5.1)" that means that emails are sent out through the email service provider without a user name or password.

            In other words, you email service provider does not implement #1 "SMTP with authentication" authentication methodology, so you shouldn't use that setting in your machine. Instead, your Machine's settings should be changes to 1 of the two possibilities below:

            "2. SMTP without authentication required" or "3. POP3 before SMTP"

            To determine which one of these methodologies apply, you can run the next test shown below while you are still in the same telnet session:

            Type: MAIL FROM: You@yourDomainName.com
            It will respond: 250 OK
            Type: RCPT TO; John@OurDomainName.com
            It will respond: DATA
            It will respond: 354 go ahead
            Type: SUBJECT: This is a test
            Type: your message
            On the last line type nothing, but hit "ctrl-d"
            ************************************************** *****

            If the above email arrives at its intended destimation without a problem, you know that SMTP authentication was not required to send it.
            Change your setting accordingly, if that is the case.

            The bottom line is that you need to know what authentication methodology your external email service provider has implemented (and therefore should be used by your machine. Specifically - does it use 1. SMTP with authentication, 2. SMTP without authentication or 3. POP before SMTP. Once you know the authentication methodology requirements, you can change your Machine's settings accordingly.

            I hope this helps.

            Comment

            • aesthetics1
              Trusted Tech

              100+ Posts
              • May 2010
              • 148

              #7
              This is a lot simpler than you think it is.

              Do you have or have you ever configured the machine in question??

              Please note that the manufacturer states the following:

              The default SMTP port cannot be changed.

              SMTP Authentication is not supported.


              Originally posted by Morton & Associates
              First off - the technology used behind email communications has not changed, nor has it been "modernized" in general, for well over 10 years, if not 20.
              Spam has caused several of the popular carriers within the last 10+ years to change over from anonymous SMTP to SMTP authentication required due to the fact that in the past they were used as relays by spammers. Some may be on anonymous systems still, but many have switched over.

              Not only has this changed recently, but SSL has become more and more sought since identity theft and data protection on the wire has been on the minds of all business professionals. This machine does not support SSL, or changing the default SMTP port from port 25. This can't be worked around.

              Originally posted by Morton & Associates
              The question is can your machine be configured to support all three types of SMTP "authentication?"

              I'd bet the answer is yes, because, SMTP authentication hasn't changed for a very long time.
              This machine does not support SMTP authentication. This cannot be worked around.

              Originally posted by Morton & Associates
              ..."modern" Bizhubs have the same "problem."
              Not true. "Modern" bizhubs use the proprietary Emperon controller, and fully support POP before SMTP, SMTP authentication, as well as anonymous transfer, SSL, TLS, and a host of other more modern (characteristic of present and recent time; contemporary; not antiquated or obsolete), more commonly used email methods.


              Originally posted by Morton & Associates
              Quick solution - Find out what authentication methodology your email service provider has implemented by process of elimination.
              He has already stated in a previous post that his e-mail server uses SMTP authentication, described as your "Method #1" which the machine simply does not support.

              You have some very good info and I do not mean to attack you but sending someone on a wild goose chase when the machine will never do what they need it to is unwarranted.

              As I suggested in my previous posting, an internal SMTP server used as a relay such as ArGoSoft (exclusively recommended for this exact issue by the manufacturer of the machine) will work to route e-mail from the machine to other in-house e-mail clients. This isn't as complicated to set up as it sounds whether you have tons of experience in the field or none at all.

              For reference:

              Description:
              Support for outgoing authentication to a customer E-mail provider.
              Solution:Description:
              FORWARD TX error message and unable to scan to E-mail.

              Solution:
              CAUSE: SMTP authentication is ON.

              SOLUTION: Disable SMTP authentication.


              NotesDescription:
              Unable to authenticate to an external SMTP server when scanning to E-mail.
              Solution:
              CAUSE: The standard controller is not equipped with SMTP authentication.

              SOLUTION: Install an SMTP relay server application (i.e., ) in the local segment/domain if authentication to an external E-mail server is necessary.





              Also attached is Konica Minolta's configuration instructions for Argosoft.
              Attached Files

              Comment

              • CT Copier Repair
                Trusted Tech

                250+ Posts
                • Mar 2010
                • 304

                #8
                DOn't ya love IT guys telling us that it will work
                I have had too many of these people tell me that their obsolete copier must be able to
                they don't stop to THINK

                they have upgraded their equipment 5 times since they bought the copier but the copier MUST be able to do this
                never stopping to think that 5-10 year old machines cannot do it without manufacturer support

                I LOVE THIS

                Comment

                • aesthetics1
                  Trusted Tech

                  100+ Posts
                  • May 2010
                  • 148

                  #9
                  Originally posted by ct copier repair
                  DOn't ya love IT guys telling us that it will work
                  I have had too many of these people tell me that their obsolete copier must be able to
                  they don't stop to THINK

                  they have upgraded their equipment 5 times since they bought the copier but the copier MUST be able to do this
                  never stopping to think that 5-10 year old machines cannot do it without manufacturer support

                  I LOVE THIS
                  I totally agree!... Upgrade your machine! You've been through how many different versions of Windows/Quickbooks/Office/Proprietary business software, but you still want your MFP to be able to interface flawlessly with technology 10 years it's junior?.. Give me a break!

                  Comment

                  • Morton & Associates
                    Junior Member
                    • Aug 2009
                    • 6

                    #10
                    Originally posted by aesthetics1
                    This is a lot simpler than you think it is.
                    SMTP Authentication is not supported.
                    This machine does not support SMTP authentication. This cannot be worked around.

                    He has already stated in a previous post that his e-mail server uses SMTP authentication, described as your "Method #1" which the machine simply does not support.
                    Have a look at Page 2-21. It asks for an email password. I doubt the copier fetches email.

                    RFC 2554 was written by J. Myers in March of 1999:



                    His copier is more "modern" then the RFC, but the copier was made 5 years after the RFC.
                    OK.

                    Originally posted by aesthetics1
                    Not only has this changed recently, but SSL has become more and more sought since identity theft and data protection on the wire has been on the minds of all business professionals. This machine does not support SSL, or changing the default SMTP port from port 25. This can't be worked around.
                    SSL is not "SMTP with authentication" and can take place over port 25, as my examples showed.

                    Originally posted by aesthetics1
                    Not true. "Modern" bizhubs use the proprietary Emperon controller, and fully support POP before SMTP, SMTP authentication, as well as anonymous transfer, SSL, TLS, and a host of other more modern (characteristic of present and recent time; contemporary; not antiquated or obsolete), more commonly used email methods.
                    I don't think he's concerned with "modern trends" he needs a solution to his problem. These are good things to know, if that's what he wants. But he hasn't said so.

                    Originally posted by aesthetics1
                    You have some very good info and I do not mean to attack you but sending someone on a wild goose chase when the machine will never do what they need it to is unwarranted.
                    If the problem is that the machine can't handle SMTP authentication - then that's all you have to say. But sorry, I'm not convinced it lacks that feature, the manual implies otherwise.

                    All the rest is an attack, first on his machine (of which his reasons for using it are his business) and the subsequent editorial on email authentication options that he's not even using.

                    How is firing up the administrative web page on the machine and looking for an SMTP authentication option "a Wild Goose Chase??"


                    Originally posted by aesthetics1
                    As I suggested in my previous posting, an internal SMTP server used as a relay such as ArGoSoft (exclusively recommended for this exact issue by the manufacturer of the machine) will work to route e-mail from the machine to other in-house e-mail clients. This isn't as complicated to set up as it sounds whether you have tons of experience in the field or none at all.
                    Sounds like a wild goose chase.

                    Comment

                    Working...