Blocking MX query

Wed Sep 5 03:06:13 UTC 2012

On 9/4/12, Mark Andrews <marka at isc.org> wrote:
> In message
> <CAArzuost70Yq=KfXHXZSOV+ptg6apiDzm71=FhCS+Ty_yo5OAA at 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.

> --
> Mark Andrews, ISC
--
-JH