[Top] [All Lists]

Re: [ietf-smtp] Possible contribution to moving forward with RFC5321bis SMTP

2020-01-01 12:40:31
Hash: SHA1

In message 
Keith Moore <moore(_at_)network-heretics(_dot_)com> writes

And since this would be entirely new practice, it would at least be 
possible to require Organization Validation or Extended Validation 
certificates as a condition of accepting mail, or more likely, as a 
condition of not pessimizing mail... 

We cannot prescribe whether a receiver is going to accept email, you can
merely state what the correct protocol is for the transfer and for
efficient signalling of accept/reject decisions.

and/or set up email-specific CAs 
for the purpose of authenticating SMTP clients.

I don't claim that it's simple to make this work - the devil is, as 
always, in the details.   I don't think there is a magic bullet.   But I 
do see client cert authentication of SMTP-over-TLS as another potential 
tool in the toolbox.

No-one in the world of large scale transfer thought that server certs
from existing CAs (or DANE and its reliance on DNSSEC) were going to
work reliably at scale ... so the bulk handlers of email went for (and
have deployed) MTA-STS (RFC8461) instead.

I doubt that the views of the practicality of using client certs would
be all that different.

Note that the driver for MTA-STS was nothing to do with preventing abuse
in the sense its used in this thread so far (the bad guys are far better
at adopting new standards, configuring correctly etc than the good guys
are) ... but to address the threat of events such as BGP hijacks causing
mail flows to go to the wrong place... or middleboxes removing
encryption from connections

- -- 
richard                                                   Richard Clayton

Those who would give up essential Liberty, to purchase a little temporary 
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755

Version: PGPsdk version 1.7.1


ietf-smtp mailing list

<Prev in Thread] Current Thread [Next in Thread>