I am curious about what network operators are doing with outbound SMTP
traffic. In the past few weeks we have ran into over 10 providers,
mostly local providers, which block outbound SMTP and require the users
to go THOUGH their mail servers even though those servers are not
responsible for the domains in question! I know other mail servers are
blocking non-reversible mail, however, is this common? And more
importantly, is this an acceptable practice?
Most of our smaller ISPs that we support; we allow any outbound SMTP
connection, however we do watch residential users for 5+ outbound SMTP
connections at the same time. But if the ISP has their own mail
servers, and users wish to relay though them, we basically tell them to
use their mail server that they contract with. What is the best
practice?
I am curious about what network operators are doing with outbound SMTP
traffic. In the past few weeks we have ran into over 10 providers,
mostly local providers, which block outbound SMTP and require the users
to go THOUGH their mail servers even though those servers are not
responsible for the domains in question! I know other mail servers are
blocking non-reversible mail, however, is this common? And more
importantly, is this an acceptable practice?
It's both unacceptable in my opinion and common. There are even those
misguided souls that will tell you it is best practice, though general agreement,
even among them seems to be that only 25/tcp should be blocked and that
465 and 587 should not be blocked.
Most of our smaller ISPs that we support; we allow any outbound SMTP
connection, however we do watch residential users for 5+ outbound SMTP
connections at the same time. But if the ISP has their own mail
servers, and users wish to relay though them, we basically tell them to
use their mail server that they contract with. What is the best
practice?
Best practice is to do what works and block as much SPAM as possible without
destroying the internet in the process. There are those who argue that blocking
25/tcp does not destroy the internet. By and large, they are the same ones who
believe NAT was good for us.
> I am curious about what network operators are doing with outbound
SMTP
> traffic. In the past few weeks we have ran into over 10 providers,
> mostly local providers, which block outbound SMTP and require the
> users to go THOUGH their mail servers even though those servers are
> not responsible for the domains in question! I know other mail
> servers are blocking non-reversible mail, however, is this common?
> And more importantly, is this an acceptable practice?
>
It's both unacceptable in my opinion and common. There are even those
misguided souls that will tell you it is best practice, though general
agreement, even among them seems to be that only 25/tcp should be
blocked and that
465 and 587 should not be blocked.
[dmb] I would agree, for residential customers, if they use the "ISP"
domain, then yes they should relay though the ISPs mail server. For
business customers and other residential customers that do NOT use the
ISP domain, then I think they should use their own mail server that they
already pay for.
>
>
> Most of our smaller ISPs that we support; we allow any outbound SMTP
> connection, however we do watch residential users for 5+ outbound
SMTP
> connections at the same time. But if the ISP has their own mail
> servers, and users wish to relay though them, we basically tell them
> to use their mail server that they contract with. What is the best
> practice?
>
Best practice is to do what works and block as much SPAM as possible
without destroying the internet in the process. There are those who
argue
that blocking 25/tcp does not destroy the internet. By and large, they
are
the same ones who believe NAT was good for us.
Owen
[dmb] Lots of smaller ISPs out there run thousands of customers though
NAT and I can see the need to properly "monitor" the SPAM activity on
those IPs, not saying that is right, but I do see the point, in this
event. But for ISPs that are handing out publics, I don't see how
blocking outbound Port 25 helps, other than makes more support calls for
the end users. Keep in mind that, ATT DSL and the local cable co here
in STL, both block outbound port 25, but a simple phone call or e-mail
to their support and they will remove the block.
Blocking outbound TCP SYN packets on port 25 from non-servers is
considered a BEST PRACTICE to avoid being the source of snowshoe and
botnet spam. Blocking it from legitimate mail servers... does not make
sense.
The SMTP submission port (TCP 587) is authenticated and should
generally not be blocked.
This sadly is very common. It is getting more common by the day it seems but
this practice has started almost a decade ago.
An easy work around is to use a custom port as they seem to just block port
25 as a bad port but leave just about everything else open including 2525
which seems to be a common secondary smtp port for hosting companies.
Interesting... Most people I know run the same policy on 25 and 587 these
days...
to-local-domain, no auth needed.
relay, auth needed.
auth required == TLS required.
Anything else on either port seems not best practice to me.
Due to the absurd things I've seen done in the world, I actually
run that policy on 5 ports:
25, 587 as you would expect.
465 SSL rather than STARTTLS, but, otherwise identical
80 because it works when nothing else does.
443 because sometimes Deep Packet Inspection is a PITA.
Of course, using 80 and 443 requires the use of additional IP address
resources for those servers rather than being able to also run a web
server on the same address, but, this is the consequence of replacing
an internet with 64K ports with filters that force the entire internet to
operate all services on TCP/80.
With this combination, I have not encountered a hotel, airport lounge, or
other poorly run environment from which I cannot send mail through my
home server from my laptop/ipad/iphone/etc.
With this combination, I have not encountered a hotel, airport lounge, or
other poorly run environment from which I cannot send mail through my
home server from my laptop/ipad/iphone/etc.
Ever heard of this magical thing called a VPN?
Indeed, that bypasses all those crappy local networks; and yes don't
worry your iToy also has more than ample VPN abilities.
Set up once and never have to bother about special configurations or
getting around stupid filters.
With this combination, I have not encountered a hotel, airport lounge, or
other poorly run environment from which I cannot send mail through my
home server from my laptop/ipad/iphone/etc.
Ever heard of this magical thing called a VPN?
Sure, but, why deal with the overhead? Who wants to have to login to a
VPN every time just to quickly retrieve or send some email?
Indeed, that bypasses all those crappy local networks; and yes don't
worry your iToy also has more than ample VPN abilities.
Some do, some don't, and not all networks are any friendlier to VPNs
than they are to port 25.
Set up once and never have to bother about special configurations or
getting around stupid filters.
Except where you have to or where there are so many layers of NAT that
even VPNs don't work, or...
I set up the 5 ports once and don't need any special configurations to
get around stupid filters, stuff just works now.
1) You don't even really *care* if they do or not, because...
2) if some other site is running with an un-AUTHed open port 587, the miscreants will
find it and abuse it just like any other open mail relay. The community will
deal with it quick enough so you don't have to. And at that point, it's the
open mail relay's IP that ends up on the block lists, not your mail relay's IP.
Other people running open port 587s tends to be quite self-correcting.
With this combination, I have not encountered a hotel, airport lounge, or
other poorly run environment from which I cannot send mail through my
home server from my laptop/ipad/iphone/etc.
Ever heard of this magical thing called a VPN?
Sure, but, why deal with the overhead? Who wants to have to login to a
VPN every time just to quickly retrieve or send some email?
On that iToy of yours it is just a flick of a switch, presto.
Indeed, that bypasses all those crappy local networks; and yes don't
worry your iToy also has more than ample VPN abilities.
Some do, some don't, and not all networks are any friendlier to VPNs
than they are to port 25.
And the final solution then tends to be setting up a VPN on port 443...
Which only wastes one IP address, not several for different services.
Set up once and never have to bother about special configurations or
getting around stupid filters.
Except where you have to or where there are so many layers of NAT that
even VPNs don't work, or...
Unless this 'NAT' is actually a firewall doing DPI on the packets, I
can't see any reason why a VPN which just uses TCP over port 443 can't
work in that situation.
It's both unacceptable in my opinion and common. There are even those
misguided souls that will tell you it is best practice, though general agreement,
even among them seems to be that only 25/tcp should be blocked and that
465 and 587 should not be blocked.
The document is signed by all major ISPs in Norway as well as the
Norwegian research and education network operator, so it must be
considered a local "best practice" whether you like it or not.
Note that only port 25/tcp is blocked and that some of the ISPs offer a
per-subscriber optout.
If they are using someone else's mail server for outbound, how, exactly do you control
whether or not they use AUTH in the process?
1) You don't even really *care* if they do or not, because...
2) if some other site is running with an un-AUTHed open port 587, the miscreants will
find it and abuse it just like any other open mail relay. The community will
deal with it quick enough so you don't have to. And at that point, it's the
open mail relay's IP that ends up on the block lists, not your mail relay's IP.
But that applies to port 25 also, so, I'm not understanding the difference.
Other people running open port 587s tends to be quite self-correcting.
With this combination, I have not encountered a hotel, airport lounge, or
other poorly run environment from which I cannot send mail through my
home server from my laptop/ipad/iphone/etc.
Ever heard of this magical thing called a VPN?
Sure, but, why deal with the overhead? Who wants to have to login to a
VPN every time just to quickly retrieve or send some email?
On that iToy of yours it is just a flick of a switch, presto.
On anything, a VPN is a diversion of your traffic through a tunnel with additional
overhead for encryption and encapsulation headers.
Indeed, that bypasses all those crappy local networks; and yes don't
worry your iToy also has more than ample VPN abilities.
Some do, some don't, and not all networks are any friendlier to VPNs
than they are to port 25.
And the final solution then tends to be setting up a VPN on port 443...
Which only wastes one IP address, not several for different services.
Meh, there are plenty of IP addresses. The shortage is limited to this legacy
v4 stuff. When the hotel networks and such catch up to the modern internet,
I can stop running these extra addresses on IPv4 and it won't matter.
Set up once and never have to bother about special configurations or
getting around stupid filters.
Except where you have to or where there are so many layers of NAT that
even VPNs don't work, or...
Unless this 'NAT' is actually a firewall doing DPI on the packets, I
can't see any reason why a VPN which just uses TCP over port 443 can't
work in that situation.
You would think, but, I have seen them break. OTOH, most of my VPNs
are IPSEC, not SSL, so that's another issue. There would be significant
additional overhead in setting up an SSL VPN. Admittedly, it's one-time
overhead, but, again, I don't see a reason to bother.
I'm curious how a traveller is supposed to get SMTP relay service
when, well, travelling. I am not really sure if I want a VPN for
sending a simple email.
And I can understand (although I am not convinced that doing so is
such a great idea) blocking 25/tcp outgoing, as most botnets will try
that method of delivery. However, I do believe that outgoing 465
SHOULD always be allowed.
Blocking outbound TCP SYN packets on port 25 from non-servers is
considered a BEST PRACTICE to avoid being the source of snowshoe and
botnet spam. Blocking it from legitimate mail servers... does not make
sense.
The SMTP submission port (TCP 587) is authenticated and should
generally not be blocked.
Interesting... Most people I know run the same policy on 25 and 587 these
days...
Owen,
Perhaps you misunderstand the issue. The issue is not relaying mail
through someone else's mail server, it's delivering mail to a mailbox
served by that mail server. 99.99 etc. percent of the time when that's
done directly from a IP address that's supposed to be user PC it's
some form of spam. Hence the best practice within the email community
is to ask the networking community to block those packets outright.
And its why residential ISPs who fail to tend to find their way into
Spamcop, Spamhaus and others. Facilitating that sort of network
filtering is precisely why authenticated SMTP relaying was assigned
port 587 instead of leaving it on port 25.
I'm curious how a traveller is supposed to get SMTP relay service
when, well, travelling. I am not really sure if I want a VPN for
sending a simple email.
That's what the SMTP submission port (TCP 587) is intended for and
it's why outbound 587 should not be blocked. In fact, blocking 587 can
cause problems with folks who use the Sender Policy Framework to
restrict the servers allowed to pass mail from a particular domain
outward.
I'm curious how a traveller is supposed to get SMTP relay service when, well,
travelling. I am not really sure if I want a VPN for sending a simple email.
And I can understand (although I am not convinced that doing so is such a
great idea) blocking 25/tcp outgoing, as most botnets will try that method of
delivery. However, I do believe that outgoing 465 SHOULD always be
allowed.
regards
Carlos
[dmb] This is the exact question, why, do you NEED a SMTP Relay on ANY network. Your domain has a mail server out on the net that if you authenticate to, I am sure will relay your mail, and the reverse DNS and SPF records would match then as well. Why does the local internet provide NEED to relay though their server, regardless of the port.
