Tag: SMTP

SMTP Stopped Sending Mail to Office 365

Had a client whose SMTP server suddenly stopped sending scan to e-mails to their domain cloud Office 365 e-mail from their on-premise SMTP server. The queue folder quickly filled up with over a hundred e-mails, so what could have caused this problem?

After three days of troubleshooting, I finally figured it out. In the event log, I was seeing the following issue:

A total of three IP addresses were rejecting the mail, which never even left the queue folder to generate a log in the badmail folder. The three IP addresses were ‘207.46.163.42’, ‘207.46.163.74’, and ‘216.32.180.10’. A cursory search on Google revealed these to be Microsoft servers.

Now this worked perfectly just a few days ago, with no error message like it in the event logs prior to the 23rd of January, 2018. Could it really be this simple of a fix? I tried resetting IIS 6.0, started and stopped the SMTP service many time. I added smtp.office365.com as a smart host, I added a relay as detailed in several websites (including Microsoft’s), and I event played with different settings. Nothing worked… but I did notice occasionally a few e-mails would kick off at a time before failing again as I made changes. Now, I can’t say I know a lot about TLS, but it is my understanding that TLS required authentication and had to go across port 587.

Apparently not. I went back into IIS 6.0 Manager and right clicking on SMTP Virtual server and went to properties. Under the delivery tab, I clicked Outbound Security… at the bottom. There I clicked TLS encryption. I made zero other changes.

I clicked OK and then clicked apply. I didn’t even have to restart the SMTP service – all the e-mail in the queue folder cleared out within moments. Finally, a victory. As a final test, I sent test scans to our domain e-mail account from the Xerox SMTP configuration as well as sending another IT technician to send scans at the printers to themselves. It all worked like it should.

I’m not entirely sure why this works, but I would love if someone could fill me in. Remember, it worked days ago, then suddenly it stopped working until I enabled TLS encryption. I did not configure any ports other than 25.

SMTP Scan to Email failing

This issue perplexed me for far longer than it should have. Being a rookie in the ways of the network world, I had yet to learn of all the paths one can take to solve an issue quickly. After all, solving issues can be hard if you don’t know where to look to begin with.

A client was having issues with their SMTP server and Scan to E-mail. The first issue involved large documents being split into several e-mails. The second issue would be that the client would not always receive the scans in their inbox at all, without any errors, though this issue was very intermittent, so most scans were making it to their destinations.

The printer vendors swore that it was not their problem (which is true), so I was tasked to help solve it. After trouble shooting and looking at settings, I was scratching my head as to what exactly could be causing the problems. Being an intermittent issue, it was hard to say why some were making it through and others were not. The printer settings were correct, split large files was disabled, and the spam filters were set to allow all e-mails from the printers to everyone’s inbox.

Now we did narrow it down to the SMTP server itself as using a test Gmail account for their SMTP worked just fine. But what exactly was happening on that server?

After spending well over a month and the issue escalating to critical, I was able to get help from one of the senior staff.

We poked around in the SMTP server. Lo and behold, the SMTP server was set to split large files. The SMTP server has the power to override any setting on the printers. Increasing allowed file size meant that the scans were no longer being split into different e-mails. Finally, the first issue was solved.

Now what could be causing the scans to not always go to the user’s inbox? After digging around further, I discovered the .BAD logs. Opening them in notepad revealed undeliverable headers with the reasons why the e-mails were failing.

Before I say why, during the course of trying to find some sort of logs that could point to why these issues were happening I found that the SMTP server utilized several IP addresses to send the e-mails. So when I found the undeliverable headers, they showed just a single IP address as being blocked. Now this makes sense! Because the IP addresses used were mostly random, several would work just fine. That is until the blocked IP was used.

So who was blocking the IP? Microsoft.

So the client contacted Microsoft to have that IP delisted from the blocked list and everyone lived happily ever after.

It is just a shame it took me so long to figure all this out. However it was certainly a learning experience.