On Thu, May 05, 2016 at 06:30:38PM -0000, John Levine wrote:
> >I think the primary virtue of accepting HTTP/S reports is really in the
> >case where the recipient has a severely misconfigured MTA. ...
>
> I don't understand this argument at all. STS and DMARC both publish a
> reporting URL which is usually mailto:<something>. There is no need
> for the address in the mailto: to have any connection to the domain
> being reported, and more often than not it doesn't.
If there is a close match in the requirements for DMARC reporting
and the requirements for the proposed reporting for forward-path
authentication errors (beyond the fact that both are reports about
email sent across organizational boundaries) that case has not yet
been made in sufficient detail.
I agree that some lessons about data formats and the like are likely
applicable, but I am far less convinced that outsourcing analytics
for as with DMARC applies in this new context.
The most timely reporting mechanism may be neither HTTPS nor a
separate email report, but an ESMTP extension that can signal
authentication errors as they occur. (Since STS supports a
non-enforcement 'trial' mode, and reporting was in large measure
intended to support that, the client would be continuing to use
the server in any case).
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
