Dr. I Doctor's Informational Juggernaut
Dear Doctor,
We've recently seen a sudden increase in reports of lost email — email our users send that recipients never receive. Last month we moved our System i email server to a collocation facility, which entailed changing the server's IP address. Everything seemed to be working fine, but now this problem has cropped up. The colo facility manager sees no connectivity or traffic problems, and we're receiving no bounce or other error messages. What would cause only certain messages to be dropped?
Gentle User,
Dr. I Doctor wishes you had provided more detailed information about the kind of messages being dropped. Are all messages to particular destinations dropped? Or only those mailed from certain originators? Is there any kind of pattern? Alas, you are not here to answer these queries, so Dr. I Doctor will have to use the shotgun approach.
But first the answer to your last question: What would cause only certain messages to be dropped? The unhappy answer is that not all mail servers apply the same rules when accepting inbound mail. Some will take mail from anybody, others conduct various tests to try to reject potential spam and malicious emails before they gain a foothold on user computers. Dr. I Doctor suspects your mail server is being misidentified as harmful. Common practice dictates that harmful messages be dropped with no warnings, which might give interlopers insight into a destination mail server's filter process.
The first check to conduct is an easy one: see whether your mail server is listed on any email blacklists. You can do this easily at senderbase.org, a site that will match your mail server's IP address and domain name against dozens of potential blacklists. If you're on a blacklist, SenderBase will direct you to instructions for remediation. Addressing whatever caused your server's blacklisting in the first place will likely solve your problems.
If you're not blacklisted, the second most common problem is incorrect DNS information for your mail server's IP address, a plausible concern given you just changed that address. A reverse-DNS lookup on the IP address must return a name, and a DNS lookup on that name, in turn, must return the original IP address. A failure of either test means your mail server looks a lot like a spoofing source, one from which many reputable mail servers will refuse to accept mail.
The third most common problem is server misconfiguration. Often you simply have a spelling error in the server's official name in the mail configuration file. For example, if your server is named "postmaster.acme.com" and you inadvertently have "toastmaster.acme.com," the greeting message your server gives to other servers might not be universally accepted, causing outbound mail dropping.
A fourth issue is an incorrect Sender Provider Framework (SPF) DNS record value. Although not required, when an SPF record exists, it must accurately list the mail servers authorized to transmit mail for your domain. Given the recent move of your mail server, if you have an SPF (always a good idea) and forgot to update it with your mail server's new IP address, recipients that check the SPF record would drop your transmissions.
Posted by mbeckman at September 1, 2008 4:04 PM

| Sun | Mon | Tue | Wed | Thu | Fri | Sat |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | ||||
| 4 | 5 | 6 | 7 | 8 | 9 | 10 |
| 11 | 12 | 13 | 14 | 15 | 16 | 17 |
| 18 | 19 | 20 | 21 | 22 | 23 | 24 |
| 25 | 26 | 27 | 28 | 29 | 30 | 31 |
We welcome your comments and opinions and encourage lively debate on the issues. However, Penton Media reserves the right to delete or move any content that it may determine, in its sole discretion, violates or may violate its Terms of Use or is otherwise unacceptable. For more information, see Penton Media's Terms of Use.