On Wed, Jan 20, 2021 at 1:21 PM Michael Thomas <[email protected]> wrote:
> I just scanned through DMARC and I couldn't find any security > requirements/mechanisms for the failure reports. I would think at the > very least the receiver consuming the reports ought make certain that > the report at the very least have either a valid DKIM signature or a SPF > pass. Unauthenticated data is always the source of mischief, and I'm > sure that there have to be attacks that are possible with > unauthenticated reports. At the very least this should be a security > consideration, and most likely should have some normative language to > back it up. > I thought the usual rules about when you should or shouldn't trust a message ought to be applied, but I guess we never actually said that in the document. We certainly could. Since I'm sort of new, it's been unclear to me whether whether having a > new https transport mechanism is in scope or not -- it seems to come up > pretty often -- but I'm not sure how people would propose to > authenticate the report sending client. That seems to me to be a basic > security requirement for any new delivery method. The problem here is > there isn't a client certificate to determine where the report is coming > from or any other identifying mechanism. An alternative might be to DKIM > sign the report itself, but the long and short is that it would need to > be addressed. > As I recall DMARC originally (in its pre-RFC versions) did have "https" as a supported scheme for "rua", but since nobody implemented it during the years DMARC was in development, it got dropped before publication. -MSK
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
