Yeah, that bit for validating the A->B relationship (section 7.1) is not
currently in the TLSRPT spec. Of course it's fairly trivially applicable,
but we left it out of the current draft (complexity, etc).
Do you think we should be including that if we support HTTP reporting?
Yes, definitely, for the same reasons DMARC does. If you're a large
hosting provider doing mail under various brands, you'd probably want to
do the analysis at one place, and it seems to me that the kind of stuff
Agari does for DMARC would be useful here.
Seems like a CNAME could accomplish the same in that case, unless we
require cert validation (which strikes me as pointless if we allow
plaintext SMTP).
Random CNAMEs and SNI play poorly together. Might as well just use the
TXT record to point people at the real name of the server.
R's,
John
On Thu, May 5, 2016 at 1:01 PM, John R Levine <[email protected]> wrote:
"The PUT method requests that the enclosed entity be stored under the
supplied Request-URI. If the Request-URI refers to an already existing
resource, the enclosed entity SHOULD be considered as a modified version
of the one residing on the origin server. "
Seems like it would require the reporter to be claiming a unique URI, no?
Yes, that's a feature to weed out duplicate reports. See section 7.2.1.1
of the DMARC spec (RFC 7489) for an example of how to come up with a
suitably unique name. I suppose for PUT you might want to use slashes
instead of exclamation marks.
Do remember that it's a feature that you can send reports for domain A to
a report recipient in domain B, so you can aggregate all of your reports
and use outsourced analysis providers.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
