Blocking MX query
marka at isc.org
Tue Sep 4 22:22:28 CDT 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
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
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
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