It has been long heard that many ISPs block outgoing port 25 for the purpose
of reducing spam originated from their network.
I wonder which ISPs are still doing so. I know comcast has been doing that
but they cancelled it after many complaints. It seems to be the same case
for Verizon.
AT&T is the major one that I know of that is still enforcing this policy.
But they said they can unblock port 25 upon request. I am not sure how easy
it is.
One simple way to test if your ISP is blocking outgoing port 25 is to try:
"telnet mx2.hotmail.com 25" or "telnet gmail-smtp-in.l.google.com 25". If
the connection fails, it could be due to the fact your ISP is blocking
outgoing port 25, although it can also be other reasons such as local
firewall configuration. Can someone perform the test and let me know result
if possible? Thanks a lot!
We still do it and never get any complaints - we don't filter static IP
customers but dynamic customers can either use our SMTP relays or
alternate ports....
It has been long heard that many ISPs block outgoing port 25 for the purpose
of reducing spam originated from their network.
Well blocking or redirecting to there servers, which have an undocumented filtering policy. All one needs to do in order to bypass that is use a vpn. Something lightweight like n2n could be used by the bot herders of the world.
I worked for a company that sent out several hundred thousand messages per day (an online card/invitations company). We ran spam assassian on our outbound farm, to prevent folks from using us to send spam. I presume the large service providers do the same.
AT&T is the major one that I know of that is still enforcing this policy.
But they said they can unblock port 25 upon request. I am not sure how easy
it is.
It's trivial. A web form. You get the link when you try to send mail to port 25 anywhere else. At least with Yahoo/SBC dsl.
I got the business class DSL from AT&T and no such nonsense exists.
Yes, it is standard practice for non-server accounts and most dynamic-only
accounts; only allow unauthenticated smtp traffic to your own smtp servers.
If you are not running server-to-server traffic at the end of that broadband
pipe, then you should be shifting your userbase to authenticated on the SUBMIT
port [587] anyway...
I wonder which ISPs are still doing so. I know comcast has been doing
that but they cancelled it after many complaints. It seems to be the
same case for Verizon.
You're mistaken. Comcast most certainly does port 25 filtering,
although not necessarily on every line at every moment. So does
Verizon, AT&T, and every other large North American consumer ISP I
know.
Look, kids, it's not 1998 any more. These days outgoing traffic to
port 25 is approximately 99.9% botnet spam, 0.1% GWL, and 0%
legitimate mail. Blame the botnet herders and the vendors of cruddy
software that year after year still is full of trivial exploits. If
you can make the botnets go away, I will be happy to lead the charge
to unblock all those ports.
If it's important to you to have an unfiltered connection, pay for
business service that has a static IP, or arrange to tunnel to some
host that does.
Except for those ISPs who choose to intercept port 587 as well. This is
a big problem with Rogers in Vancouver. They hijack port 587 connections
through some sort of lame proxy that connects you to your intended host,
but strips the AUTH field out of the EHLO response from the remote
submission server ...
in all seriousness, most isp's (consumer provider folk) today do some
form of blocking of port 25, if you are 'smart' enough to evade this
sort of thing, then you can still do email/blah. 99.999% of users are:
1) not interested in bypassing it
2) not clued into what's going on
3) using webmail
in all seriousness, most isp's (consumer provider folk) today do some
form of blocking of port 25, if you are 'smart' enough to evade this
sort of thing, then you can still do email/blah. 99.999% of users are:
1) not interested in bypassing it
2) not clued into what's going on
3) using webmail
I'd say 0.5% of my customer base contacts the helpdesk to setup auth and bypass tcp/25 blocks using tcp/587. Another 2% use my webmail offsite, and about 10% use webmail only (on my network or off).
Then there's those pesky gmail users. We should just block them. j/k
Why is this debate still ongoing??
Because nanog is slow? Actually, I think the original poster was just curious as these days not much is said overly much outside of the "Die Spammer" threads in other venues.
We just open port 2525 for customers from ISP's blocking official SMTP
ports so they can use their dedicated servers/domain mailservers.
for personal use, i have a box that has sshd running on 443 and i tunnel
2525 through it. that worked even in the narita red rug when they were
at their blocking worst.
for customer use, i would push them to 465, 587 if less clued.
I am the ISP, and we currently don't. However, I inherited this setup and have been slowly fixing glaring holes (those are fairly well gone now) and not so glaring one. When our new firewall gets in, I will be rolling in port 25 blocks on dynamic IP addresses. The static ips will be unfiltered. Customers may send outbound mail through our SMTP server, or connect via alternate ports to their SMTP server.
AT&T is the major one that I know of that is still enforcing this policy.
But they said they can unblock port 25 upon request. I am not sure how easy
it is.
It's trivial. A web form. You get the link when you try to send mail to port 25 anywhere else. At least with Yahoo/SBC dsl.
I got the business class DSL from AT&T and no such nonsense exists.
Same here with U-Verse and a /29 of static IP's. No blocking since Day 1.
Those same clueless ISPs will probably block 2525 someday too, clueless expands to fill any void. And using non-standard things like 2525 only lead to more confusion for customers later when they try someone else's non-standard choice, e.g. port 26 or 24 or 5252 and wonder why those don't work.
On the other hand, why don't modern mail user agents and mail transfer agents come configured to use MSA port 587 by default for message submission instead of making customers remember anything? RFC 2476 was published over a decade ago, software developers should have caught up to it by now. Imagine if the little box in Outlook and Exchange had the MSA port already filled in, and you only needed to change it for legacy things.
