Blocking MX query

Mailman List Mirror (Read Only)
21

There are no "good" subscribers trying to send email direct to a
remote port 25 from behind a NAT. The "good" subscribers are either
using your local smart host or they're using TCP port 587 on their
remote mail server. You may safely block outbound TCP with a
destination of port 25 from behind your NAT without harming reasonable
use of your network.

Would that were true going forward. Consider a world where your
home is chock full of purpose built devices, most likely with an
embedded web browser for configuration where you have a
username/password for each. In the web world this works because
there is a hidden assumption that you can use email for user/password
reset/recovery and that it works well.

Hi Mike,

A. What device do you offer as an example of this? I haven't stumbled
across one yet. Web sites yes. Physical home devices, no.

What I *have* seen is devices that call out to a web server, you make
an account on the remote web server to configure them and then all the
normal rules about accounts on remote web servers apply.

I want to buy hardware from people, not their ill-conceived "cloud"
service that dies when there's no more business case for it and is probably
evil anyway.

B. Bad hidden assumption. Expect it to fail as more than a few cable
and DSL providers are blocking random port 25 outbound. Besides, some
folks change email accounts like they change underwear. Relying on
that email address still working a year from now is not smart.

I'm well aware of port 25 blocking. I'm saying your assumption
that there is *never* any reason for a home originating port 25
traffic is a bad one. It's never been a good one, but the collateral
damage was pretty low when NAT's are in the way. v6 will change
that, and the collateral damage will rise. Unless you can come up
with another ubiquitous out of band method for account recovery,
expect the tension -- and help desk calls -- to increase.

Mike

22

Ah; so then the End-To-End Principle is *not* The Prime Directive.

Good; thanks. Can we stop flogging people with it who like DNAT, then?

Cheers
-- jra

23

Suresh Ramasubramanian wrote:

Have your desktop MTA configured to relay through your smarthost with smtp
auth? Howtos for doing this on sendmail, qmail, postfix etc are over a
decade old now.

What if, your home is also behind NAT or blocked port 25?

            Masataka Ohta

24

Who cares about NAT when you say smtp auth rather than allowing relay for
specific IPs? And if you mean your smarthost is a linux box in your home,
it isn't impossible to get static IP broadband .. which is neither natted
nor port 25 filtered.

25

One can begin to envision a spam avoidance scheme; where a mail server
is assigned a random IP within an IPv6 prefix based on a EUI64/UUID.
Two static MX records are published; each MX referencing short-lived
AAAA records with a TTL of 60 seconds or less.

One of those AAAA records points to the current IP address of the
mail server, and one of those AAAA records point to the "next one".
A mail server binds to each address both "previous" and "next" and
accepts port 25 connections for mail delivery.

Every 60 seconds, the "current address" AAA record is changed to
the IP listed in the "next address" AAA record; a new EUI64 is
generated, and the "next address" AAAA record is populated with the
new randomly generated IPV6 address.

A mail server for the domain binds the new IP address and starts
listening; and starts tarpitting any new port 25 connections from the
previous address in 90 seconds.

After 600 seconds, or when the IP is no longer in the most recent 5,
an6 existing SMTP connections to the old server IP (from unacceptably
slow senders/deliveries) are terminated, and the server removes the
old IP from its interface.

26

MUA's can make MX queries to validate entered addresses
  before SMTP/SUBMISSION is even attempted.

27

Weren't you the one who a few weeks ago was advocating more NAT rather than
deploying IPv6?

28

Sure but not on this guy's network as he's transparently proxying dns
and blocking MX requests on his proxy

Of course a bot can build up a rich cache of MX records from elsewhere
and send from a botted 3g modem connected host on his network

29

>
> MUA's can make MX queries to validate entered addresses
> before SMTP/SUBMISSION is even attempted.
>

Sure but not on this guy's network as he's transparently proxying dns
and blocking MX requests on his proxy

Well he was looking for software to block the queries. There is a
whole mentality that homes don't need X which on closer examination
just doesn't bear up to scrutany. This includes blocking SMTP or
don't you think home users are entitled to have privacy when it
comes to whom they email?

STARTTLS from anywhere to anywhere is possible today and is not
vulnerable to interception except in the MX's themselves. You can
secure the MX records (and their absense) and secure the CERTs used
by STARTTLS.

30

This is a bit of a slippery slope. There is broad agreement that SPs
need to block port 25 outbound (and inbound) on dynamic IP space.

And he did say he's in a country where he's obliged by law to filter
out porn (and I guess anything else his country's government doesn't
like).

Where do blocking MX record lookups fit in between the porn blocking
and the port 25 filtering? Rather closer to port 25 filtering I'd
say, but your call.

This is not a user privacy issue at all. Static IP broadband is
entirely available if you should decide you want to run a mailserver
at your home. And for people using outlook (or postfix) on their
desktop to relay through a smarthost, MX lookups don't matter one way
or the other.

--srs

31

This is not the thread for this conversation per se. The practicality of general ISP 25 blocking is established for antispam purposes. So are power users running home domains. Different user profiles. Different circumstances.

George William Herbert

32

All, thanks for the input and comment. In summary, I will block TCP port
25. My DNS loadbalancer (F5) can filter MX query and need license to do it.
But given the information the botnet use address list with
pre-resolved IP addresses then blocking MX query is not the answer :slight_smile:

Thanks & Regards
Ibrahim

33

In message
<CAArzuost70Yq=KfXHXZSOV+ptg6apiDzm71=FhCS+Ty_yo5OAA@mail.gmail.com>, Suresh
Ramasubramanian writes:
STARTTLS from anywhere to anywhere is possible today and is not
vulnerable to interception except in the MX's themselves. You can
secure the MX records (and their absense) and secure the CERTs used
by STARTTLS.

You can also use SMTPS on port 465; or STARTTLS on port 587. Most MX
servers don't support TLS or SSL, so it could be privacy neutral, and
many MX server operators utilize dynamic host RBLs, even if STARTTLS
connections are allowed. It is possible for end user to tunnel SMTP
traffic over VPN, SSL, or SSH to a private submit server on a trusted
network.

Blocking initial outgoing TCP SYN for port 25 completely creates a
predictable failure scenario. which is to be encouraged.

ISPs very commonly block outgoing initial SYNs to that port. And
ISPs also commonly block 23, 135 - 139, 190, 389, 445, 1025, 1080,
1433 - 1434, 3380, 3389, 5060, 5070, 5631, 6667, 31337, 559.

Some may block connections to all outgoing ports, except a small
number. Those are all accepted practices, with increasing
annoyance, and increasing predictable breakage, the more ports are
messed with.

Blocking few/no ports is desirable; and port 25 is so widely blocked,
that MUAs should be set to 587 + authenticated submit in the first
place.

Tampering with the contents of packets, "blocking" application level
traffic by creating fake application layer error messages, for example
fake nxdomain/servfail response, or fake "550 rejected" SMTP
response, is to be strongly discouraged, because it causes
unpredictable application failures.

ISP routers aren't supposed to reject/accept packets based on
application layer data.

The exception would be you manage the end user computers, and dictate
a very precise list of applications, so you can pick ones whose
vendors list it as a supported thing, or you have gone through
rigorous testing procedures. (Enterprise IDS units, that analyze
packets and seek to block attacks by reacting to application content,
are OK, for example)

Of course a bot can build up a rich cache of MX records from elsewhere
and send from a botted 3g modem connected host on his network

Yes. It can also "probe" randomly for servers listening on port 25
based on A record lookup instead of MX, or by using Reverse DNS to
find a domain, and then guess e-mail addresses.

34

> In message
> <CAArzuost70Yq=KfXHXZSOV+ptg6apiDzm71=FhCS+Ty_yo5OAA@mail.gmail.com>, Suresh
> Ramasubramanian writes:
> STARTTLS from anywhere to anywhere is possible today and is not
> vulnerable to interception except in the MX's themselves. You can
> secure the MX records (and their absense) and secure the CERTs used
> by STARTTLS.

You can also use SMTPS on port 465; or STARTTLS on port 587. Most MX
servers don't support TLS or SSL, so it could be privacy neutral, and
many MX server operators utilize dynamic host RBLs, even if STARTTLS
connections are allowed. It is possible for end user to tunnel SMTP
traffic over VPN, SSL, or SSH to a private submit server on a trusted
network.

You missed the point. It *is* a privacy problem if my ISP can see
the "MAIL TO: <user@example.net>". It is *unreasonable* to expect
everyone to run their own submission server to avoid this privacy
problem.

Most MX's don't *currently* support STARTTLS because until recently
it was difficult to prevent various MiM interception attacks and
you had to pay for CERTs. Both of these reasons are in the process
of going away. You can prevent MiM on MX records by using DNSSEC.
You can generate and publish your own CERT records using DANE.

Blocking initial outgoing TCP SYN for port 25 completely creates a
predictable failure scenario. which is to be encouraged.

Only if you don't care for user privacy. There is way to much data
collection already.

35

NAT, here, means dumb NAT. With most, if not all, pseudo ISPs using
NAT, you can't expect port forwarding services.

While ISPs in the future should use not IPv6 but NAT with fixed
IP addresses and sets of port numbers assigned to their customers,
keeping the end to end transparency, it does not solve the
problem of blocked port 25.

Note that IPv6 do not solve the problem of blocked port 25, either.

            Masataka Ohta

36

So - now with ipv6 you're going to see "hi, my toto highly
computerized toilet is trying to make outbound port 25 connections to
gmail"

http://www.telecoms.com/48734/vodafone-and-ibm-team-up-on-connected-home-appliances/

37

Gives a new meaning to a sh*** connection. Or perhaps to flushing a mail queue...

David