On Sat, 18 Nov 2017, at 01:28, Eliot Lear wrote: > I've been watching the back and forth and trying to get my > hands around> the technical issues between the two cases. The closest I see > for a > technical explanation in this thread is this: > > > On 11/17/17 3:55 AM, Viktor Dukhovni wrote: >> As I pointed out in another message, BOTH REQUIRETLS=YES >> **and** REQUIRETLS=NO need to be encapsulated in headers, but >> the YES case **also** needs an ESMTP extension, while the >> NO case does not. It makes sense to define both in the >> same document. > > For those of us who were not in the room, can someone explain the case> in > technical detail for **not** doing REQUIRETLS=NO in the same > document?> Jim? > > Eliot
That's a great summary of the key point, and I totally agree with Viktor here, though I would even more strongly argue that definining REQUIRETLS=NO as an ESMTP extension would be a mistake. It doesn't add any additional signal on top of the header, and creates more cases where the two sets of information could be out of alignment. I would argue that if REQUIRETLS=YES is given via ESMTP then the lack of a REQUIRETLS=YES header on the same message MUST cause a rejection, meaning that nobody would deploy the YES case unless they had both in alignment. Whereas the NO case is always just a hint to intermediate sites to relax their tests. For NO a header is plenty, since you never want to stop trying to deliver just because you can't negotiate something at ESMTP for the NO case. I'm really quite happy for it to be a single document for the reasons Ned and Viktor have suggested - it's easier to get adoption. That said, I could see sites deploying NO support without deploying YES, since YES requires you to to ensure that your downstreams are at least claiming to play ball. So that's an argument for either two separate documents or the spec saying that it's legitimate to implement NO only. It's less important how many documents are produced than the ability for sites to offer NO without YES. Cheers, Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd [email protected]
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
