Hi, > On 06 May 2016, at 01:10, Viktor Dukhovni <[email protected]> wrote: > > On Fri, May 06, 2016 at 12:32:59AM +0700, Aaron Zauner wrote: >> So in that case why not prefer a secure HTTPS connection over an insecure >> SMTP connection? > > We're discussing an error reporting mechanism, not a secure message > delivery mechanism. It should be possible to deliver the bad news > even under adverse conditions.
We're discussion a _feedback_ mechanism, at least that's what I understood from the draft. > If the reports contain sensitive data, let's simplify the reports > to contain less of it. In most cases, a boolean "your cert chain > fails to verify for domain D at MX host H" is quite sufficient. What if I want to send sensitive information about delivery failures? I.e. the way a MITM was attempted? > > The SMTP message would be sent via opportunistic TLS, with fallback > to cleartext if STARTTLS fails or is not adverised. See above. Opportunistic TLS is the wrong approach here in my opinion. I never liked it and I never will. I think the reasons are obvious. Aaron
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
