Port25 blocking

laura
Industry
January 14, 2016

A number of hosting providers are blocking outgoing port25. This has implications for a lot of smaller senders who either want to run their own mail server or who use SMTP to send mail to their ESP.

What is port25

Port25 is the designated email sending channel. Much like websites are on port80 (or 8080) and DNS is on port53, email is sent over port25. Mostly.

Why block Port25

Port25 blocking is a way for hosting providers to control and monitor the mail their customers send. They can block any ongoing connections on port25. Typically the hosting company provides a mail relay for all customers to use.
The big benefit of port25 blocking is preventing infected machines from having access to big pipes to send malicious mail. While we mostly talk about botnets infecting Windows machines, there are a large number of compromised Linux machines, too. The hosting company can run outbound filters on the server they control and force all their customers to send through that server.

Challenges with Port25 blocking

Senders who are hosted at a company that blocks port25 can have problems sending bulk mail. Some senders use port25 to send mail from their internal servers to their ESP. If they’re behind a port25 block, this won’t work. There are, however, still ways to get email to the ESP.

What can you do if you’re port25 blocked?

First is contacting your provider and asking them to open port25 for your systems. We had to do this recently when spinning up IPv6. By default our provider blocks port25 on IPv6. There were some hoops you need to jump through, but they took Steve only an hour or two to accomplish.
Second is contacting your ESP and seeing if they accept mail in ways other than port25. Some ESPs are supporting port587 for mail, others have APIs that don’t use SMTP for email submission.
Third is using a cloud service to generate your mail. I know a number of companies who use AWS systems to create messages that are then sent out through their ESP.
Overall, port25 blocking is a good thing. It is a security improvement. Yes, it does inconvenience some people, but usability is starting to take a back seat to security these days.

Trawling through the junk folder

As a break from writing unit tests this morning I took a few minutes to go through my Mail.app junk folder, looking for false positives for mail delivered over the past six weeks.
trashcans
We don’t do any connection level rejection here, so any mail sent to me gets delivered somewhere. Anything that looks like malware gets dumped in one folder and never read, anything that scores a ridiculously high spamassassin score gets dumped in another folder and never read, mailing lists get handled specially and everything else gets delivered to Mail.app to deal with. That means that Mail.app sees less of the ridiculously obvious spam and is mostly left to do bayesian filtering, and whatever other magic Apple implemented.
There were about thirty false positives, and they were all B2C bulk advertising mail. I receive a lot of 1:1 mail, transactional mail and B2B marketing mail and there were no false positives at all for any of those.
All the false positives were authenticated with both SPF and DKIM. All of them were for marketing lists I’d signed up for while making a purchase. All of them were “greymail” – mail that I’d agreed to receive, and that was inoffensive but not compelling. While I easily spotted all of them as false positives via the from address and subject, none of them were content I’d particularly missed.
Almost all of the false positives were sent through ESPs I recognized the name of, and about 80% of them were sent through just two ESPs (though that wasn’t immediately obvious, as one of them not only uses random four character domain names, it uses several different ones – stop doing that).
If you’d asked me to name two large, legitimate ESPs from whom I recalled receiving blatant, blatant spam recently, it would be those same two ESPs. Is Mail.app is picking up on my opinions of the mail those ESPs are sending? It’s possible – details specific to a particular ESPs mail composition and delivery pipelines are details that a bayesian learning filter may well recognize as efficient tokens.

Are botnets really the spam problem?

Over the last few years I’ve been hearing some people claim that botnets are the real spam problem and that if you can find a sender then they’re not a problem. Much of this is said in the context of hating on Canada for passing a law that requires senders actually get permission before sending email.
Botnets are a problem online. They’re a problem in a lot of ways. They can be used for denial of service attacks. They can be used to mine bitcoins. They can be used to host viruses. They can be used to send spam. They are a problem and a lot of people spend a lot of time and money trying to take down botnets.
For the typical end user, though, botnets are a minor contributor to spam in the inbox. Major ISPs, throughout the world, have worked together to address botnets and minimize the spam traffic from them. Those actions have been effective and many users never see botnet spam in their inbox, either because it’s blocked during send or blocked during receipt.
Most of the spam end users have to deal with is coming from people who nominally follow CAN SPAM. They have a real address at the bottom of the email. They’re using real ISPs or ESPs. They have unsubscribe links. Probably some of the mail is going to opt-in recipients. This mail is tricky, and expensive, to block, so a lot more of it gets through.
Much of this mail is sent by companies using real ISP connections. Brian Krebs, who I’ve mentioned before, wrote an article about one hosting company who previously supported a number of legal spammers. This hosting company was making $150,000 a month by letting customers send CAN SPAM legal mail. But the mail was unwanted enough that AOL blocked all of the network IP space – not just the spammer space, but all the IP space.
It’s an easy decision to block botnet sources. The amount of real mail coming from botnet space is zero. It’s a much bigger and more difficult decision to block legitimate sources of emails because there’s so much garbage coming from nearby IPs. What AOL did is a last resort when it’s clear the ISP isn’t going to stop spam coming out from their space.
Botnets are a problem. But quasi legitimate spammers are a bigger problem for filter admins and end users. Quasi legitimate spammers tend to hide behind ISPs and innocent customers. Some send off shared pools at ESPs and hide their traffic in the midst of wanted mail. They’re a bigger problem because the mail is harder to filter. They are bigger problems because a small portion of their recipients actually do want their mail. They’re bigger problems because some ISPs take their money and look the other way.
Botnets are easy to block, which makes them a solved problem. Spam from fixed IPs is harder to deal with and a bigger problem for endusers and filters.

Politics and Delivery

Last week I posted some deliverability advice for the DNC based on their acquisition of President Obama’s 2012 campaign database. Paul asked a question on that post that I think is worth some attention.