Spam, delivery, email and more
ReturnPath announced yesterday that SenderScore Certified now covers 1.2 billion inboxes, including mail handled by Hotmail, Time Warner Cable, GoDaddy and eventually Yahoo. A number of filters are also using SSC, including Spam Assassin, IronPort Systems, Barracuda Networks and Cloudmark.
This time e360 is in court suing a number of individuals for calling him a spammer.
Mickey has docs up on SpamSuite.com and Ken Magill has written about it as well.
Dave has also responded to ReturnPath, through Ken, with a public letter explaining why his statement disagrees with ReturnPath’s statement about his acceptance into the SenderScore Certified program.
Rumor has it that Dave is claiming he is out of money. If that’s true, who is funding these cases?
Russell from Port25 posted a comment on my earlier post about changes at Comcast.
Our (Port25) understanding is that Comcast is rate limiting such that they’re only accepting 6 recipients per second per sending IP.
This matches what I’ve been hearing from other bits of the industry over the last few days. I am recommending clients close the connection between each set of 6 email addresses.
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.
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.
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:
Comcast has transmitted fraudulent bounce information to e360’s mail servers specific to email addresses contained on e360’s opt-in marketing list. The responses sent by Comcast mail servers to e360 are fraudulent because they contain information indicating that the email address is invalid and not active. As an email marketer, e360 relies on bounce information from Comcast’s mail servers to determine whether e360’s customer email addresses are still active and deliverable. e360 has information and reason to believe Comcast is intentionally transmitting fraudulent bounce information to e360 in an attempt to discourage e360 from sending additional email messages. By transmitting fraudulent bounce information, Comcast is effectively destroying e360’s proprietary assets and the value contained in e360’s opt-in database of email addresses. Such statements are made on information and belief as only Comcast has access to and knowledge of the accounts it has and will not allow e360’s emails to be delivered regardless of account activity.
I really do not think that Comcast is maliciously and deliberately faking that addresses are dead in order to destroy e360’s business. It just does not pass the sniff test. Why would Comcast do that? What possible benefit could there be to doing that?
Another interesting bit of the complaint is e360’s assertion they have been approved for the SenderScore Certified program offered through ReturnPath. Ken interviewed George Bilbrey. According to Ken
However, George Bilbrey, head of Return Path’s delivery assurance unit said e360 had not been certified.
“He applied and didn’t gain admittance to the program,” Bilbrey said, declining to elaborate.
The punchline is e360 is suing Comcast for around 21 million dollars because Comcast is being MEAN and, well, here’s what e360 has to say:
58. At the same time that Comcast is blocking e360’s email messages that are compliant with Comcast’s polices, Comcast is allowing other email marketers with substantially similar business practices as those employed by e360 to send email messages to Comcast’s customers.
59. Comcast’s refusal to deliver email sent by e360 while allowing its competitors to freely transmit email puts e360 at a disadvantage and creates an un-level playing field on which e360 must compete.
60. Upon information and belief, Comcast has made agreements, either written or verbal, to allow certain email marketers to send or transmit email without interruption regardless of whether such email meets Comcast’s Acceptable Use policy. Based on these agreements, Comcast has applied its policies with certain email marketers in a way that is materially different than Comcast’s application of its policies to e360’s email messages. Such statement is made upon information and belief because only Comcast can verify with whom they have agreements with to allow mail to be sent to their customers.
It will be interesting to see what happens once the judge reads the complaint. In my very non-legal opinion I am not seeing a real cause of action here. There is case law and statutory law that says ISPs have the ability to filter mail to their subscribers. Apparently e360 thinks they can convince a judge to ignore facts and law in order to make Comcast stop being mean to them.
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
<redacted@aol.com>: host mailin-03.mx.aol.com[205.188.109.56] said: 550 We would love to have gotten this email to redacted@aim.com. But, your recipient never logged onto their free AIM Mail account. Please contact them and let them know that they’re missing out on all the super features offered by AIM Mail. And by the way, they’re also missing out on your email. Thanks. (in reply to RCPT TO command)<redacted@aol.com>
The poster was confused because the addresses were aol.com addresses that had successfully delivered in the past. He was unsure why AOL would be rejecting good aol.com addresses with the aim.com.
After some investigation and some discussion with a friendly AOL representative, the underlying reason for this sudden increase in rejections became clear. The mailer was seeing an increase for two interacting reasons.
The increase in bounces is the result of pulling older addresses and the @aol.com addresses getting @aim.com bounces is the result of AOL’s policy of converting abandoned aol addresses to aim addresses.
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.
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.
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.
