Re: Blocking MX query

[Mark Andrews <marka () isc org>]

In message <CAAAwwbXMXhS+8w2CV90b8x9XJ0omvhTmWDY+WMyCPw6GiWfZMQ () mail gmail com>, Jimmy Hess writes:
> On 9/4/12, Mark Andrews <marka () isc org> wrote:
> > 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.

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