MP3500 wont scan to email

[techman3826]

I saw someone else had a similar prob on a mp4500...
I have replaced control board, BICU, print scan option,NVRam..
this machine SMB scans just fine.
they have a exchange server through smtp port 25. it requires authentication.

The cust also has a xerox 4150 and it scans to email just fine.

[cobiray]

Can you get a successful connection test to the SMTP server in the user tools? Have you tried using the server name and the IP address? Do you have DNS numbers that work properly? If all of that is good, you might try asking them to set up an email address for the MFP that does not expire with a simple password for testing.

[Ricoh-ono]

Change SP 5-860 "SMTP Auth. From Field Replacement" to On. By doing this, Scan to Email will pass the SMTP authentication.
Note: Using this option to solve the above problem, the device email address will appear in the email's "From" field. The email address of the user who sent the email will appear in the "Reply-to" field.
[Explanation]
This is an SMTP authentication issue that aborts transmission of an already started Scan to Email. Currently this has only been reproduced using MS-Exchange server.
MS-Exchange requires that all of the following match:
1) The sender's address in the "MAIL FROM" field. This is also known as the "envelope sender" or "MIME sender". It is an SMTP command sent at the beginning of the email transmission process.
2) The sender's address in the mail header "From:" field. This appears as "From" in email clients. It is a part of the email itself.
3) The email address corresponding to the SMTP username used to login into the SMTP server.
When the MFP logins into the SMTP server, the email address of the username 3) will be compared to 1) and 2). If these comparisons fail, authentication will also fail. Exchange server will stop the transmission procedure, and the "Transmission has failed" message will be returned to the sender.

Here is a typical example:

NG case:
SP5-860 is Off:
1) The "MAIL FROM" field = device
2) The mail header "From:" field = user
3) The SMTP username = device )

When the SMTP server compares 2) and 3) the Exchange Server will stop the transmission procedure.

OK case:
SP5-860 can be used to make the values in the above example, match.
In this example, if SP5-860 is On, the user's email address in the mail header '2)' will be replaced by the Administrator's email address.
To solve the problem, the Administrator's address must be the same as the device's address.
If this is done:
1) The "Mail From: field = device
2) The mail header "From:" field = administrator
3) The SMTP username = device

1,2 and 3 must match and the authentication should be successful.
Note: The user's email address will still be inserted into the reply-to field.

[fausto1981]

-Do you get an error code???
-Are you able to do a succesfull "Connection Test"
-Check the system log under IPv4. it will tell you why it is failing
-Make sure you have the right info like
DNS, SMTP, Default Gateway.

-you said that they have an Exchange server right, are you able to send emails internally, don't send them outside their Domain, try sending something within their domain.

-Add the IP address of the Copier on the relay in system manager on the server.
-Sometimes when the security is pretty tight, it has to be a valid e-mail address, if you just type a generic e-mail address like info@customers_domain.com the server will block the e-mail.

[unisys12]

I have also found that you should ask who the customers ISP is. If they are using an ISP, such as AT&T or whoever, and their network is built off this connection - you will have to enter a valid ISP email for this to work.

Example - We recently set up a Savin 8060 and 2824 on demo. At the same location, there was already a Cannon (not sure of the model) there on demo as well. Before I started anything, I asked the customer for a list of any names of users that will be scanning and their e-mail address. I also asked for their ISP and valid ISP e-mail account username. This confused a few people, because their company had their own e-mailed hosted onsite, so they called their head network staffer and had me talk to them. Sure enough, they were using a local cable ISP, but I knew those lines were leased through Comcast. I also knew that Comcast will not allow for our MFP's to send e-mail through their domain into another without a valid Comcast e-mail. When I explained this, the network personal knew exactly what I needed and looked it right up. I then entered their ISP SMTP IP in the for SMTP server name (which was of course different than their Exchange server IP) and their company's ISP e-mail name in the administrators e-mail section (which again was different than their company e-mail) and walla!

When this happens, you of course want to leave off the option to "auto attach sender name".

After I got both of our machines printing and scanning, which took all of 20 minutes, the network person asked how we could make our machine scan to e-mail and the Cannon guys couldn't. I explained, "I asked one more question then they did. That's all." We closed the deal yesterday, I think.

One more quick note... I have found that when customers lease T1 lines or something to that effect, the above rules don't always apply. Most of time, these customers stay within their own domain and don't put a high priority of direct scan to e-mail. These are customers that most likely will utilize scan to folder, ftp or ncp. If they push the issue though, either the above option or Ricoh-ono's might work. I haven't used that method will look into for future reference.

[techman3826]

yes connection test is successfull...also remember i can scan to email with same settings through a xerox device in thier office that we put thier so that they can scan to email until we figure out thier Ricoh.

[cobiray]

I know this is an old thread, but I faced a similar issue this week. I had what I was told was "good" SMTP authentication credentials. Needless to say it didn't work when sending a scan job. The connection test through the user tools worked and I could ping the I.P. What I did to test the machine and rule it out as a problem was to use a known good mail server (the one at our office) and "hijacked" it to send the email. We don't use SMTP authentication but even if you had a known good one, you could still rule out the machine as faulty. You could conceivably use a Comcast or Verizon email server for testing, although do it at your own risk. Hope this helps somebody out next time they've got a scan to email problem.