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.

CASL botnet take down

biohazardmail The CRTC served its first ever warrant as part of an international botnet takedown. The warrant was to take down a C&C (command and control) server for Win32/Dorkbot. International efforts to take down C&C servers take a lot of effort and work and coordination. I’ve only ever heard stories from folks involved but the scale and work that goes into these take downs is amazing.
Bots are still a problem. Even if we manage to block 99% of the botnet mail out there people are still getting infected. Those infections spread and many of the newer bots steal passwords, banking credentials and other confidential information.
This kind of crime is hard to stop, though, because the internet makes it so easy to live in one country, have a business in a third, have a shell corp in a fourth, and have victims in none of those places. Law enforcement across the globe has had to work together and develop new protocols and new processes to make these kinds of takedowns work.

June 2015: the Month in Email

Happy July! We are back from another wonderful M3AAWG conference and enjoyed seeing many of you in Dublin. It’s always so great for us to connect with our friends, colleagues, and readers in person. I took a few notes on Michel van Eeten’s keynote on botnets, and congratulated our friend Rodney Joffe on winning the prestigious Mary Litynski Award.
In anti-spam news, June brought announcements of three ISP-initiated CAN-SPAM cases, as well as a significant fine leveled by the Canadian Radio-television and Telecommunications Commission (CRTC) against Porter Airlines. In other legal news, a UK case against Spamhaus has been settled, which continues the precedent we’ve observed that documenting a company’s practice of sending unsolicited email does not constitute libel.
In industry news, AOL started using Sender Score Certification, and Yahoo announced (and then implemented) a change to how they handle their Complaint Feedback Loop (CFL). Anyone have anything to report on how that’s working? We also noted that Google has discontinued the Google Apps for ISPs program, so we expect we might see some migration challenges along the way. I wrote a bit about some trends I’m seeing in how email programs are starting to use filtering technologies for email organization as well as fighting spam.
Steve, Josh and I all contributed some “best practices” posts this month on both technical issues and program management issues. Steve reminded us that what might seem like a universal celebration might not be a happy time for everyone, and marketers should consider more thoughtful strategies to respect that. I wrote a bit about privacy protection (and pointed to Al Iverson’s post on the topic), and Josh wrote about when senders should include a physical address, what PTR (or Reverse DNS) records are and how to use them, testing your opt-out process (do it regularly!), and advice on how to use images when many recipients view email with images blocked.

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.