Port25 blocking

biohazardmailA 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.

Related Posts

Do system administrators have too much power?

Yesterday, Laura brought a thread from last week to my attention, and the old-school ISP admin and mail geek in me felt the need to jump up and say something in response to Paul’s comment. My text here is all my own, and is based upon personal experience as well as those of my friends. That said, I’m not speaking on their behalf, either. 🙂
I found Paul’s use of the word ‘SysAdmin’ to be a mighty wide (and — in my experience — probably incorrect) brush to be painting with, particularly when referring to operations at ISPs with any significant number of mailboxes. My fundamental opposition to use of the term comes down to this: It’s no longer 1998.
The sort of rogue (or perhaps ‘maverick’) behavior to which you refer absolutely used to be a thing, back when a clean 56k dial-up connection was the stuff of dreams and any ISP that had gone through the trouble to figure out how to get past the 64k user limit in the UNIX password file was considered both large and technically competent. Outside of a few edge cases, I don’t know many system administrators these days who are able to (whether by policy or by access controls) — much less want to — make such unilateral deliverability decisions.
While specialization may be for insects, it’s also inevitable whenever a system grows past a certain point. When I started in the field, there were entire ISPs that were one-man shows (at least on the technical side). This simply doesn’t scale. Eventually, you start breaking things up into departments, then into services, then teams assigned to services, then parts of services assigned to teams, and back up the other side of the mountain, until you end up with a whole department whose job it is to run one component of one service.
For instance, let’s take inbound (just inbound) email. It’s not uncommon for a large ISP to have several technical teams responsible for the processing of mail being sent to their users:

Read More

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.

Read More

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.

Read More