Blocking MX query

Mark Andrews marka at isc.org
Wed Sep 5 03:22:28 UTC 2012


In message <CAAAwwbXMXhS+8w2CV90b8x9XJ0omvhTmWDY+WMyCPw6GiWfZMQ at mail.gmail.com>, Jimmy Hess writes:
> 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.

You missed the point.  It *is* a privacy problem if my ISP can see
the "MAIL TO: <user at 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.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org




More information about the NANOG mailing list