Recent Posts

Comcast rate limiting

Russell from Port25 posted a comment on my earlier post about changes at Comcast.

Sources tell me that AOL announced on yesterday’s ESPC call that they are now, and have been for about a week, checking DKIM inbound. This fits with a conversation I had with one of the AOL delivery team a month or so back where they were asking me about what senders would be most concerned about when / if AOL started using DKIM.
The other announcement is that AOL, like Yahoo, would like to know how you categorize your outgoing mail stream as part of the whitelisting process.
Both of these changes indicate to me that AOL will be improving the granularity of their filtering scheme. DKIM signing will let them separate out different domains and different reputations across a single sending IP address. The categorization will allow AOL to evaluate sender statistics within the context of the specific type of email. Transactional mail can have different statistics from newsletters from marketing mail. Better granularity means that poor senders will be less able to hide behind good senders. I expect to hear some wailing and gnashing of teeth about this change, but as time goes on senders will clean up their stats and their policies and, as a consequence will see their delivery improve everywhere, not just AOL.

Update on Yahoo and the PBL

Last week I requested details about Yahoo rejections for IPs pointing to the PBL when the IP was not on the PBL. A blog reader did provide me with extremely useful logs documenting the problem. Thank you!
Based on my examination of the logs, this appears to be a problem only on some of the Yahoo! MXs. In fact, in the logs I was sent, the email was rejected from 2 machines and then eventually accepted by a third.
I have forwarded those logs onto Yahoo who are looking into the issue. I have also talked with one of the Spamhaus volunteers and Spamhaus is aware of the issue as well.
The right people are looking at the issue and Spamhaus and Yahoo are both working on fixing this.
Thanks for the reports and for the logs.

e360 in court again

Today’s edition of Magilla Marketing announced that Dave Linhardt and e360 have sued Comcast. Spamsuite.com has the text of the complaint up.
On the surface this seems quite silly. e360 is alleging a number of things, including that Comcast is committing a denial of service attack against e360 and locking up e360’s servers for more than 5 hours. Additionally, e360 is laying blame at the feet of multiple spam filtering companies, including Spamhaus, Trend Micro and Brightmail.
One of the more absurd claims is that Comcast is fraudulently transmitting ‘user unknown’ messages. At no point do they explain how or why they think this is the case, but simply assert:

AOL and AIM mail

Earlier this week a question came up on a mailing list. The questioner recently started seeing an increase in rejections to @aol.com addresses. These rejections said

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.

PBL and Yahoo

A few days ago I posted about Yahoo using the Spamhaus lists. In the comments of that post there have been multiple reports of mail being bounced from Yahoo with a reason of “on the PBL” but the IP was not on the PBL.
I am happy to look into this for people. I’m sure neither Spamhaus nor Yahoo want to be incorrectly rejecting email. To do this, though, I need the rejection message from Yahoo, the IP the mail was sent from and when it happened. Feel free to email the information to laura at wordtothewise.com.

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.

Changes at RoadRunner

I’ve been hearing rumors that some *.rr.com domains have been bouncing all mail sent to them. Those domains belong to customers that were moved to Comcast as part of the RoadRunner / Comcast / Adelphia purchase and customer swap. As a courtesy, RoadRunner forwarded mail to comcast for those former RoadRunner customers, but have ceased to do so.
Mail to any address in the following *.rr.com domains will no longer be delivered.
jam.rr.com
midsouth.rr.com
mn.rr.com
se.rr.com
sport.rr.com
swfla.rr.com
ucwphilly.rr.com
houston.rr.com
These addresses should be removed from your lists. These users now have Comcast addresses. You cannot just substitute the Comcast domain for the RoadRunner domain as users were required to choose new localparts. That means bobjones@houston.rr.com may not be, and probably is not, bobjones@comcast.

Yahoo and Spamhaus

Yahoo has updated and modified their postmaster pages. They have also put a lot of work into clarifying their response codes. The changes should help senders identify and troubleshoot problems without relying on individual help from Yahoo.
There is one major change that deserves its own discussion. Yahoo is now using the SBL, XBL and PBL to block connections from listed IP addresses. These are public blocklists run by Spamhaus. Each of them targets a different type of spam source.
The SBL is the blocklist that addresses fixed spam sources. To get listed on the SBL, a sender is sending email to people who have never requested it. Typically, this involves email sent to an address that has not opted in to the email. These addresses, known as spamtraps, are used as sentinel addresses. Any mail sent to them is, by definition, not opt-in. These addresses are never signed up to any email address lists by the person who owns the email address. Spamtraps can get onto a mailing list in a number of different ways, but none of them involve the owner of the address giving the sender permission to email them.
Additionally, the SBL will list spam gangs and spam supporters. Spam supporters include networks that provide services to spammers and do not take prompt action to remove the spammers from their services.
The XBL is a list of IP addresses which appear to be infected with trojans or spamware or can be used by hackers to send spam (open proxies or open relays). This list includes both the CBL and the NJABL open proxy list. The CBL list machines which appear to be infected with spamware or trojans. The CBL works passively, looking only at those machines which actively make connections to CBL detectors. NJABL lists machines that are open proxies and open relays.
The Policy Block List (PBL) is Spamhaus’ newest list. Spamhaus describes this list as