The Science behind Mail Delivery
I'm working with a customer whose IT department states, inequivocably, that as part of our services, emails sent in behalf of this customer through our bulk server are never making it to their Exchange servers. I asked them which ISP and what filters. They mentioned their their ISP and that Postini is their filter.
But Postini is NOT receiving the email and throwing it into quarantine. Postini NEVER sees the mail.
Further, if the customer sends a dedicated campaign to their own 190 employees, the mail is received, 100% deliverability. Mix these same employees with 10K of their subscribers, and suddenly mail goes missing. Threshold? Where? Why wouldn't the customer's IT staff see mail server rejecting the mail and throwing it into quarantine? If a server rejects mail, why wouldn't that server keep that in the log? What happens when a filter like Postini sits outside of an ISP. Is that even plausable, or do filters always sit inside of an ISP service or firewall?
My question, finally (I'm out of breath)... what does a bulk mail flow/schematic delivery system look like. Bulk Mail -> MTA -> Filter -> ISP -> Mail server? How do the parts work? This is a pretty technical question on how bulk email is delivered, how and where filters work in the process, where problems occur... and who/how to solve them.
Any links that provide a good read on the topic is greatly appreciated.
JB@OpenMoves
Great questions!
I'll try to tackle the mail server infrastructure question first. Postini is usually installed as an SMTP relay, where the MX records for the domain are changed to a dedicated Postini mail server, so you're correct that the sending infrastructure would look like:
This works by updating the DNS MX records for the recipient's domain to Postini's SMTP servers, then telling Postini which records it should use to deliver the mail to the ISP as expected. So in future when you try to send to that recipient, you'll find a new MX record, which points to Postini. When Postini receives the email, it uses the old MX record value to deliver to the ISP's SMTP server.
That said, there's nothing stopping additional filters or SMTP relays in between the outbound SMTP (the MTA) and the Postini SMTP server. You can check this two different ways.
Perform an MX lookup on the domain of a recipient that's not receiving the email, here's an example lookup on our Postini filtered domain: http://mxtoolbox.com/SuperTool.aspx?action=mx%3aps.emailtests.com&run=toolpage
(psmtp.com is a Postini domain). Run this on your recipient's domain and see what value is returned.
Send a single email to the recipient, then ask to view the raw source of the email once received, you'll get something along these lines:
There'll be a Received header for each SMTP node that the email passed through, including Postini and any before it. See if you spot any unusual servers along the way that appear to be filtering in addition to Postini.
In terms of what's happening to the missing email, I can see a few scenarios:
There's a volume-sensitive filter in front of Postini that's rejecting the email when it sees larger volumes. You can spot volume-sensitive filters by unusual gaps in time between Received headers (you might have to send through a few at lower volume to get through for an example). If this is true, you should see an MX record for the recipient's domain (see above) that doesn't include "psmtp.com".
Postini is not quarantining the email, but actually delivering it with a header indicating it considers it to be spam. Another filter along the way (possibly even Exchange) is then deleting the email because it's detecting Postini's rejection. There are different ways of doing this, but one such example is prepending "[Spam]" to the subject line.
There's a bug causing the MTA to not be able to deliver the message (for example, until very recently PowerMTA was unable to deliver SMTP servers ending in .255). You can diagnose this by inspecting your MTA's outbound logs. You should see a 250 OK from Postini's SMTP server. If you do not, the problem lies before or at the MTA.
So, first confirm that the first 'hop' in the SMTP chain for your recipient is actually psmtp.com. Then confirm that the email has left your MTA by checking its logs.
Quick follow up question, you mention:
When you send to their own 190 employees, in this test, are they sending to their 190 employees successfully via your bulk mail servers?
Or rather, have you been able to get email delivered to their employees via your mail servers, when sending on their behalf? If not, this could be either a SenderID failure or the Exchange server rejecting users it knows it sends for originating from outside the Exchange server. Both can be fixed!
Hi, Matt. The information is very helpful and sheds a lot of light. What are the chances that I can send some header data to you offline from this post, so that you can help me ascertain anything pertinent?
No problem - I've emailed you!
Thanks, Matt. Got that and much appreciate your assistance.
JB