Blog: SMTP

There were intermittent scanning to e-mail issues occurring with an HP Color LaserJet CM4540 MFP.  Initially, scan jobs of all sizes were having trouble going through.  There was an article found that suggested updating the firmware on the device.  After the firmware was updated, it seemed to correct issues with smaller scan jobs, but larger ones were still having issues.

When the scan jobs finished scanning the pages, the device would show on the display “SMTP Protocol Error”.  The e-mails would fail to go out.  During troubleshooting, the device could scan a 10 page document to e-mail (3 times successful), but not a color 46 page document (failed 3 times in a row). 

I tested setting the Exchange server’s hub transport settings from 10 MB to 40 MB.  E-mail sent successfully for the 46 page color scan 4 times with no problems.  What this proved was that the message size was too large to be sent through e-mail based on the e-mail size limit configured in Exchange.

If you happen to see “SMTP Protocol Error” message when trying to scan large documents, chances are the e-mail size is over the limit.


 
 

We had a user recently that was reporting excessive amounts of spam in her inbox. This company uses Postini as their filtering service, so naturally, this didn’t seem quite right. After some research, I determined that it was non-account blocking (a Postini feature) that was causing the problem. In this example, let’s assume the user is Jane Smith. Her email address is jane.smith@company.com. The spam was coming into jsmith@company.com, an alternate SMTP address in Exchange.

Non-account blocking in Postini bounces all email that comes to addresses not registered in the Postini user database. If this feature is not enabled (as was the case here), Postini does not filter the email according to the spam filters and, instead, passes it through untouched. The jsmith@company.com address was not added into the user database as either a user or an alias to a user. When Postini received email on this address, it passed it straight through to their exchange server. The exchange server recognized the recipient as a legitimate user and delivered the mail as expected.

The fix here was to enable non-account blocking and add these secondary SMTP addresses as aliases in Postini. Jane has not received any spam since then.


 

A customer had switched their POP3 email and internet service to a new ISP. Which required them to change their POP3 and SMTP settings on a couple of users' iPhones. The users were able to receive but not send email.  When initially setting up POP3 on an iPhone it requires adding the ISP's SMTP settings and then once it is configured changing it to AT&T’s which is there by default (cwmx.com). This change only has to be done if the SMTP server for the ISP is using port 25. This is because AT&T blocks port 25 on their data network for wireless and internet customers. Sometimes you can get them to unblock it for your account but that is rare.

One of the iPhone users also had a laptop that he only uses with an AT&T Express Card on the GPRS network. He could receive but not send email. Since he was accessing his POP3 account via the AT&T data network port 25 was blocked. I entered “cwmx.com” for the  SMTP server just like for the iPhone and was then able to send.


 

We recently had a customer that switched Internet service providers.  After making the switch, users were getting “sending delayed” messages from the Exchange server.  The problem turned out to be caused by mis-configured DNS settings in the Exchange 2003 SMTP service.  Some e-mails appeared to be going through fine, while others were delayed and eventually dropped.  Sometimes, messages would go through, the other person would respond, and then they’d get a delayed notification for the originally sent message.  After some e-mails that were sent to CoNetrix were completely dropped, I started looking more closely at the SMTP service configuration.  I went through every setting and eventually found some entries for the old ISP's DNS servers buried in the following location: [more]

Servers -> SERVERNAME -> Protocols -> SMTP -> Default SMTP Virtual Server -> Properties -> Delivery tab -> Advanced -> Configure

This configure allows you to specify “external DNS servers”.  Apparently, based on the name, someone thought the real “external” DNS servers should be used (instead of the local DNS service that uses the external servers as forwarders).  I removed the old ISP server entries and replaced them with the external DNS servers of the new ISP as a test.  Once I did this, e-mail started sending immediately.  I then changed the entry to the local IP of the server (so the local DNS service would be used).  Things continued to work.  Setting those DNS entries is not part of our normal server setup procedures, so I'm not sure where the DNS entries originally came from.  They may have been populated by some "wizard", so keep the SMTP DNS settings in mind if you ever have a similar problem.


 

1. ISP customer setup automation sometimes creates issues. Email from domain A to domain B works, but from domain B to domain A doesn't. Be careful if both are customers of the same ISP. Sometimes automated processes create mail domains, DNS zones, and web space for all customers. Customers that use the same ISP can experience issues (depending on mail server software used) if one customer uses ISP mail (POP/IMAP & SMTP) and the other hosts their own mail server. If ISP mail servers have mail domains set up for customers who do not use the ISP provided mail (have their own mail server), when another ISP customer who does use the ISP provided mail service attempts to relay mail through the ISP's mail servers, delivery ends up being server local instead of the server looking up the correct MX record. This usually ends up being an SMTP 550 error (user not found) rejection sent to the sender.

2. Can't send mail to AOL, join the club! If a mail domain can not send mail to AOL, it could be a number of things. The first thing to do is start a telnet SMTP session like the following: [more]

telnet mailin-01.mx.aol.com 25

The AOL server will return an error code and a web link to an article explaining why the mail was blocked. A very common error is 554 (RTR:sc) which means that your sending IP has been blocked due to too many AOL members clicking the "this is spam" link for emails that trace back to you mail server IP or domain. If you are curious about what mail is getting sent on your behalf that is being specified as spam by AOL users, you can create a feedback loop (see http://postmaster.info.aol.com/fbl/). Once you have requested a feedback loop you will be notified when a member clicks "this is spam". The email sent to you from SCOMP@aol.net will contain the complete email and header information. To be removed from an AOL block list, you must call 703-265-4670 and jump through some hoops to be removed. It takes 24-hrs for the removal to take affect.