If a system is misbehaving in some way that causes TLS problems, it may be malfunctioning in other ways that would prevent reports from making it to the appropriate place. It might be useful to get that new command (QUIT does not take an optional parameter that I'm aware) to indicate to the receiving system why you're terminating the session, but I would agree that the detailed information should be delivered outside of that session.
-- Alex Brotman Engineer, Anti-Abuse Comcast x5364 ________________________________________ From: Uta <[email protected]> on behalf of John Levine <[email protected]> Sent: Sunday, May 1, 2016 8:53 PM To: [email protected] Subject: Re: [Uta] draft-brotman-smtp-tlsrpt >One way to dramatically simplify reporting is communicate the reports >in-band. That is, when authentication of a peer fails, complete the >TLS handshake anyway, and send a suitable SMTP command that signals >some detail of the TLS authentication failure, before sending QUIT. One of the reasons DMARC reports are useful is that large domains often don't know where all their mail servers are. Sending the reports to one place makes that possible. More often than not the reports go to a third party like Agari who does the crunching. This situation seems very similar to me. Also, it would operationally be a terrible idea to demand that a provider make software changes to every single one of its mail servers just to collect a few statistics about how their TLS is working. R's, John _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
