Troubleshooting a Postini block

Mail from one of my clients is being filtered at Postini and they asked me to look into this. Not that there is anything that can be done, of course. Even before they were bought out by Google, they were the poster child for a spam filtering company that believed they could do no wrong. It was difficult, if not impossible to get a straight answer from Postini about filtering, and the only statement they would ever make in regards to blocking problems was ‘have the recipient whitelist your mail.’
It is not just that Postini will not talk with people who are blocked, they will not talk to their own customers, either. Many years ago, I was dealing with another Postini issue for a customer. This customer was a Postini customer and was sending mail to themselves to test their new ESP. Postini was blocking the mail and the customer wanted me to find out why. After a couple days of digging I did actually find a really-o truly-o human at Postini. [1] He explained to me that a single line of text, followed by an unsubscribe link was spam, always spam and nothing but spam. He also explained that the only way for that mail to be let through, was for my customer to turn off his Postini filters.
Fast forward 4 years and I once again have a customer blocked by Postini.  Usually, I tell customers there is nothing to be done for Postini blocks and that no one can find any information about them, but this customer is insistent. This particular customer has extremely clean mailing practices, sends highly relevant and wanted mail and consistently gets 95+% inbox delivery. They are not spammers, not even a little bit. Because I know this customer is so clean, I poked around a little to find some information about them. They do use the ReturnPath Mailbox Monitor so I have a copy of the headers Postini is adding. I also discovered that Postini is now providing a decoder service for their headers at https://www.postini.com/support/header_analyzer.php
The response you get back from pasting in a header is not that useful if you have found any of the numerous explanations of Postini headers, but it does show some willing. Note, there is no way to ask a question or provide feedback to Postini on the listing.
There is not much that can be done to deal with Postini filtering your email. The best you can do is have your recipients whitelist you.
[1] I believe I am the only person on the delivery end that has ever been able to actually talk to a live human at Postini, and I think that is only because I called them from the same area code they are in and some engineer decided to return the message I left on their corporate voicemail.

Legal filings this week
Spammers in the news

Related Posts

Do you know where your addresses go?

Being a deliverability consultant, I end up signing up for a lot of lists and providing email addresses to a lot of different websites I may not normally trust with my email address. The only way to manage the resulting volume of email is using a disposable address system. There are a number of commercial versions, but we built our own system.
Any time I need to sign up with a client, I create a new email address. Part of the address creation process involves making notes about where and when the address was used. When mail is received at any of the email addresses I have used, that email is appended with the data I provided at the time I signed up and forwarded to a mailbox on my main system. If an address ends up compromised or sold and getting too much mail, I can just turn it off. This system allows me to freely hand out addresses, without a large amount of mail ending up in my primary mail box.
Disposable addresses great way to monitor what my clients are doing with my email address. I have found, in at least 2 cases, that my clients are doing nothing wrong, but there are leaks in their process that lets email addresses get out to spammers. My reports of data leaking were the first they knew about any problems with their vendors or customers.
I strongly recommend any marketer who shares any data, include in that data test or seed accounts. Sign up for your own lists, using unique addresses, so that you can see what kind of mail your subscribers are receiving once they sign up at your site. If you are providing data to customers or vendors, include unique test data in each list. If you start getting unexpected mail to those addresses, you can track back to the specific vendor with the data problem.
Your email address list is one of the biggest assets your company has. Protect that asset by monitoring what others are doing with it.

Read More

Yahoo delays, part 3: Yahoo speaks

Yahoo is aware of the recent problems and have been working feverishly to fix them. A Yahoo employee posted to a mailing list earlier today, explaining some of the recent issues. The summary is:
1) The Yahoo delays are a result of a tighter spam filtering policy. The delays are the result of the system erroneously recognizing email as spam and deferring delivery. They do believe that retrying long enough will result in all mail being delivered to Yahoo recipients.
2) They have been continually making fixes to the system over the last few days and senders should see queues start to empty over the next few hours.
3) They believe the adjustments made will resolve the deferral problems. If you continue to see problems, you can contact them through the form at http://postmaster.yahoo.com/.
4) They are working to provide more self-serve information at http://postmaster.yahoo.com/ as well as timely service updates.
Loose ends from my previous Yahoo posts:

Read More

Why do ISPs limit emails per connection?

A few years ago it was “common knowledge” that if you were sending large amounts of email to an ISP the most polite way to do that, the way that would put the least load on the receiving mailserver, was to open a single SMTP session to the mailserver and then to send all the mail for that ISP down that single connection.
That’s because the receiving mailserver is concerned about two main resources when handling inbound email – the pool of “slots” assigned one per inbound SMTP session, and the bandwidth (network and disk, and related resouces such as memory and CPU) consumed by the inbound mail – and this approach means the sender only uses one slot, and it allows the receiving mailserver to control the bandwidth used simply by accepting data on that one connection at a given rate. It also amortizes all the connection setup costs over multiple emails. It’s a beautiful thing – it just doesn’t get any more efficient than that.
That seems perfect for the receiving ISP – but ISPs don’t encourage bulk senders to do this. Instead many of them have been moving from “one connection, lots of mail through it” to “multiple connections, a few messages through each”. They’re even limiting the number of deliveries permitted over a single connection. Why would that be?
The reason for this is driven by three things. One is that the number of simultaneous inbound SMTP sessions that a mailserver can handle is quite tightly limited by the architecture of most mailservers. Another is that the amount of mail that’s being sent to large ISP mailservers keeps going up and up – so there are sometimes more inbound SMTP sessions asking for access than the mailserver can handle. The third is that ISPs know that there are different categories of email being sent to their users – 1:1 mail from their friends that they want to see as soon as possible, wanted bulk mail that their users want to see when it arrives and spam; lots and lots of spam.
So ISPs want to be able to do things like accept 1:1 mail all the time, while deferring bulk mail and spam to allow them to shed traffic at times of peak load. But they can only make decisions about whether to accept or defer delivery in an efficient way at SMTP connection time – they pick and choose amongst the horde of inbound connection attempts to prioritize some and defer others, letting them keep within the number of inbound sessions that they can handle simultaneously.
But once the ISP lets a bulk mailer connect to deliver their mail, they lose most of the ability to further control that delivery as the sender might send thousands of emails down that connection. (Even if the ISP has the ability to throttle bandwidth – as some do to control obvious spam – that just means that the sender would tie up an expensive inbound delivery slot for longer).
So, in order to allow them to prioritize inbound connections effectively the ISP needs to terminate the session after a few deliveries, and then make that sender start competing with other senders for a connection again.
So ISPs aren’t limiting the number of deliveries per SMTP connection to make things difficult for senders, or because they don’t understand how mail works. They’re doing it because that lets them prioritize wanted email to their users. The same is true when they defer your mail with a 4xx response.
It might be annoying to have to deal with these limits on delivery, but for legitimate bulk mail senders all this throttling and prioritization is a good thing. Your mail may be given less priority than 1:1 mail – but, if you maintain a good reputation, you’re given higher priority than all the spam, higher priority than all the email borne viruses, higher priority than all the junk email, higher priority than the 419 spams. And higher priority than mail from those of your competitors who have a worse reputation than yours.

Read More