scan to email in ricoh equipment

[rchdesk]

I have a Ricoh equipment which I had the scan to email feature working just fine. The internet provider is different than the email provider. A month ago, the company changed the internet provider, for a cable company. We received a preconfigured router and the cable modem. The changes in the network were minimal, including a new dns server ip address (isp dns of course). After all the configuration, performed in the network, the ricoh equipment stoped working the scan to email feature. One computer also cannot send email from the email client, but is able to receive. The other computers are working fine, but only this one is not. The error message i get from outlook is that the server denied the communication, either by the user authentication or too much time waiting to stablish the communication. The email accounts are fine, since you can use the webmail based, besides the other computers have no problems sending out. Like i said, the changes were minimail, added the dns ip address to the local server and have our router pointing the new preconfigured router. The cable company said, there is not any filtering type in their router.
Any suggestion? Hope this is not too long to read

[unisys12]

If I were at this call, the first thing I would do is go to a PC that was working properly and copy all relevant e-mail info down. Return to the PC having the issue and double check all the settings. You will probably find that whatever settings are off / incorrect on the PC, keeping it from sending e-mail, are the same settings that need to be changed on the MFP.

By the way... When performing a scan to e-mail from the MFP, what error message are you getting?

[fausto1981]

Alright,

If they company changed ISP, the first thing I would do is to do ipconfig /all in one of the PCs, make sure that the PC has the right default IP, Default gateway, and ""DNS"" very important if you are using the server name of the SMTP.

another thing is to check if the SMTP requires authentication and make sure that you have the right info on the copier,

and the last option is to check what port the SMTP server uses, and make sure that the router that the new ISP company gave them is not blocking that port.

and just like Unisys told you what error message do you get???

Take care

[rchdesk]

well, the configuration at any station is the same, no change was made. The error that I get from the mfp is unable to connect with the smtp server (it's pssible to ping the smtp server from mfp)and the configuration like default gateway, smtp server, dns server is still the same. Only the dns ip address for the new isp were added to the local dns server. There is no authentication for any email. Like i said the email provider still is the same and the communication port is the default. The new router, according to the internet company has no such traffic blocking.

[fausto1981]

Everything looks fine to me, try using the IP address of the SMTP server, ping it first see if you get a reply.

to test the SMTP server from the MFP do the following,

User tools, System settings, File transfer, ((This is where you can try the IP address of the server instead of the server name))
and hit "Connection Test"

if that doesn't work then there must be a setting in the router/firewal blocking the traffic for that port. by default it should be 25 but sometimes SMTP can also use secure ports!!

[rchdesk]

Thanks to every who's taking the time to read this thread.
Fausto: I have tried to ping from the MFP, is not possible. I have used the server name as well as the ip address. However, from the pc's and the server, you receive answer to the ping command. So, there's connection. Also, I have tried nslookup command to the smtp server. The default port is 25. It's been the same before and after the ISP change.
I most have to relay, also in the information from the isp for that router config. I have no control on it. I cannot test it and they have closed the ticket saying there is not traffic blocking, which I believe, since from the pc's i can send and receive emails.
Does anybody now how can I test more extensibly the traffic to that port?. I now I can use ethereal but I don't know how to interpret that information.

[Mr Spock]

Check the ip of the computers and printer and see if they changed. Also check the subnet and gateway if not already done so. If you can get a hold of someone ant the email account check if they have installed any security patches around the time of the change over. There was an article about exchange not liking or changing some security setting via an update patch that will cause headaches for mfp's when sending emails. I have this issue with a Toshiba and a Canon. (changed to a different email account (different company) and they go through). Could not leave them like that for security issues but it proves there was a security/login issue with the customers email server.

[fausto1981]

there is a way to check the mail server and the account,
try using telnet

go to the command promp and type the following:
telnet servername 25 hit enter
helo servername
mail from: MFP_emailaddress
rcpt to: TO_emailaddress
data
type your message here

.

quit

and you should be done, if you get other messages and it doesnt let you go any further then that is why it is not working.

[unisys12]

I know this is a little dated, but I had one just like this the other day.

How I fixed it, (well, worked around it) was by entering the default e-mail account info for the administrator e-mail.

In my case, what I had was a Exchange server hosted at the customers location in another town. The MFP would not connect using the Exchange server info, since the change over to AT&T. After performing a packet capture, to retrieve any errors or other info I could get, I found that they were talking, but the connection was being reset from bellsouth. So finally I entered the Bellsouth email address for the company, which they were not using for anything, for the administrator email in the MFP. This solved the problem!

After talking with one of my managers, he said that he had run into the exact same issue at another account. They were using Bellsouth for DSL, but email was being hosted by a third party. He entered the companys bellsouth email, just as I did, and again... the problem was solved.

[rchdesk]

Unisys.
Thanks. I'l try that as soon as possible, but what did you use for packet capture, ethereal?. Do you have any info or manual to interpret the packets?. I'm using ethereal but as much as I can identify, I don't see any problem in the communication establishment.

Thanks

[unisys12]

Unisys.
Thanks. I'l try that as soon as possible, but what did you use for packet capture, ethereal?. Do you have any info or manual to interpret the packets?. I'm using ethereal but as much as I can identify, I don't see any problem in the communication establishment.

Thanks

Yeah, it's ethereal, but in it's newer state as "Wireshark". Same great program. Not very familiar with Ethereal, so I couldn't give a comparison. And no, unfortunately I don't have any way to know what all those packets are off hand. What I will do when I see something in a capture that I cannot identify is later I will do a Wikipedia search on the protocol. That usually leads to the info I need to understand whats going on.

In this case, when looking at the capture, I saw the MFP trying to communicate with the Exchange Server 4 separate times. Then I would see a rest packet from the Exchange Servers IP, followed by the machine declaring the error. In the capture, the Exchange servers return info had a lot more info tagged to it, like the name "bellsouth.net". So I asked if that was there ISP and when they said yes... Walla!

After inputing the Bellsouth.net SMTP server info in place of the exchange server info (finding this by pinging mail.bellsouth.net), then placing their default bellsouth account email (finding this by taking their current email name form and adding bellsouth.net in place of their domain. Lucky, I know!) as the admin email address, it worked fine.

One more tip, since your doing packet captures as well, make sure your using a hub and not a switch either. Not saying that you are, but since packet captures came up in the conversation, I thought it should be dully noted for others who might read this later. That always seems to throw people, me included when I first started doing them.

[fausto1981]

Same thing here, I have heard of Ethereal but I wouldn't know where to look.

Thanks

[cobiray]

I had this same problem awhile back. I went back and forth with the ISP and ended up having to use SMB. While it's very inconvenient it might be a temporary option at least.

[JohnO]

We ran into something similar with a Ricoh Aficio 1060. I was Googling around and found this note.

The problem appeared after a network change. The SMTP mail server was at a remote site connected through a router. After a network change, the Ricoh could no longer communicate with the remote SMTP server. PCs could. We configured a local SMTP server on the same subnet as the Ricoh, and the Ricoh could send email to the local server. I think the Ricoh was not able to adjust its packet size smaller than 1500 bytes, and therefore communications with the remote mail server failed, while a 1500 byte packet communication with a local mail server worked fine.

I am a network person, not a Ricoh person, and am wondering if the vendor has any software/firmware update that might resolve this issue. Also - Can I check the current version of the software through the web interface?

Thanks,

John

[fausto1981]

https://tscweb.custhelp.com/cgi-bin/...?p_faqid=63827&