>I think it's certainly different in that with DMARC we can assume the >report sender can reliably (and securely, insofar as DMARC assumes SMTP >works!) reach the report recipient; with TLSRPT that's not exactly true.
>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. On my little system, I have DMARC reporting records for 114 domains that use several different MTAs, all of which send the mail to [email protected] where I have a script that parses the reports into a database. In the larger world, Agari provides a popular DMARC analysis service so you will see many thousands of domains sending their reports to the same address at Agari. For that matter, the DMARC reporting address for gmail.com is at google.com, which has a different MX so I presume is not quite the same mail system. None of these depend on the mail at the particular domain working unless that domain happens to be the one hosting the analysis server. Since the STS spec says that reports ignore the STS rules, it's hard to see how the mail could be so broken that mail reports fail without also being so broken that nobody else gets mail, either. >I would say the main goal should be a format that's easy to generate and >easy to parse, though. My totally unscientific guess is that JSON and XML >fit the bill. Being a Googler, if it were up to me I'd use protocol >buffers, but you know... ;) Well, in case nobody's mentioned it before, we do have the working large scale example of DMARC reports. You might ask around to see how well it works at Google. R's, John _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
