[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: when should we esmtps our mxes?

On Mon, 2016-10-24 at 15:15 +0000, Ivan Shmakov wrote:
> > > > > > 
> > 
> > Ben Hutchings <ben@decadent.org.uk> writes:
> […]
>  > Those certificates look as expected.  Since TLS encryption of SMTP
>  > between servers is opportunistic, there's no particular reason to use
>  > a widely trusted CA for server certificates.  A MITM can just as
>  > easily block STARTTLS as substitute their own key.
> 	That’s not necessarily any different to the HTTP(S) case.
> 	For instance, when the user first uses ‘example.com’ as the
> 	resource identifier, the Web user agent (usually) issues a GET
> 	request to the said host’s HTTP server in the plain.  At which
> 	point the server responds with a 302 redirect, pointing to the
> 	resource proper (say, https://example.com/.)
> 	That behavior is hardly any less opportunistic, and is prone to
> 	the very same attack, as demonstrated by ‘sslstrip’.

Although that's mitigated by HSTS and bookmarking of https: URLs.

> 	Yet, I’d find that quite an uncommon reason to argue that we
> 	don’t need some widely trusted CAs for the HTTPS certificates.
> 	On the other hand, my MX setup relies on ‘exim4/relay_tls_dn’
> 	files that contain the list of CNs of the remotes the MTA
> 	permits relaying mail from (that is: acts as a smarthost for.)
> 	Hence, TLS becomes rather mandatory in this case.  (Although I
> 	have to admit that I don’t currently apply this approach in the
> 	“downstream” direction with any consistency.)

Of course you can do this on a smarthost; I do the same.  I don't see
how that's relevant to lists.debian.org.


Ben Hutchings
For every complex problem
there is a solution that is simple, neat, and wrong.

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: