Vanishing emails

January 26, 2006 6:44 AM

Email stumper (for me, anyway): A site I consult on uses the IIS ASPMail module to send email confirmations for e-purchases. The customers seem to get their confirmations okay, but the site owners get theirs only intermittently...

The script CCs me on the confirmations that go to the site owners, and I get my copy for every transaction, so I know the script fires every time. The techs at the host say that the outgoing SMTP logs show no failures. The sysadmin for the site owners swears that the missing emails do not show up in his logs. Where the heck are those emails going? Much obliged if you can shed any light on this.

posted by bricoleur to computers & internet (4 answers total)

Is it possible some are getting caught in a server spam filter? If the emails are coming from the same domain, that can be flagged as suspicious by filters.

Then again, we use SoftwareArtisans' mail component for classic ASP code and we still have this problem from time to time.
posted by yerfatma at 7:16 AM on January 26, 2006

Try sending the emails to yourself and CCing the company and see if the results are the same.
posted by oh pollo! at 7:36 AM on January 26, 2006

Try sending the emails to yourself and CCing the company

That's a good idea; I'll try that.
posted by bricoleur at 8:12 AM on January 26, 2006

SMTP servers are usually configured to automatically retry deliveries for up to 5 days, often without without logging errors (depends on how the logging feature is set up, but if another server is temporarily unreachable, or unresolvable in DNS, there is little point in filling up your logs with unsuccessful connection attempts until you hit the delivery time limit). During this time, the undelivered message remains on the spool of the sending server, and a well configured server will re-attempt delivery every hour or two, until the message is sent or the delivery time limit is reached. This is all a hold over from the days when net connections were not all that reliable, and the DNS was essentially a one man volunteer operation, but it is still the default setup for most SMTP packages.

Not every site logs connection successes either, and of those that do, many prune their logs pretty quickly, especially high volume sites. Usually, at most 1 or 2 days worth of logs are kept to serve spam enforcement and administrative request needs, because if things have worked, why do admins need to know, unless there is an abuse issue in question? But if they think your messages are in fact being delivered, they should be able to provide log snippets of connection and transmission successes, if you ask. These are plaintext files you can pass along to remote site administrators to help them investigate problems on their side. They may temporarily need to turn up logging detail from standard settings to do this, or the may have a test work station they can try a command line SMTP connection from to troubleshoot your problem. Either way, they are demonstrating site-to-site connectivity and interoperation, and should be able to produce printout of successful or unsuccessful attempts.

But if you can't produce successful connection log snippets, your guys need to examine not only their SMTP error logs, but their outbound spool. If your missing messages are still on spool, they can investigate further as to why delivery hasn't been made. Often it's something as simple as a mis-configured MX (Mail Exchange) record in DNS for your correspondent domain, and an aggressive anti-spam policy on your own SMTP server, causing it to think that you have a user on your system trying to bounce SPAM messages out of your domain to open relay points, or mail zombies in other domains. Not really your guys problems to fix somebody else's bad MX records, either, but perhaps they can give the other guys a head's up.
posted by paulsc at 10:58 AM on January 26, 2006