Discussion is in scope, per: https://trac.ietf.org/trac/dmarc/ticket/42
This topic has come up before, and there's always general interest in pursuing it, and absolutely no one who puts their hand up for either it being impactful for them or having any interest in implementing it. i.e. it seems interesting to people, but there seems to be no use case with operational support to actually add it. So from those previous discussions, I don't think it's likely that we'll add reporting beyond mailto:, but it is certainly a conversation that's in scope when either ticket is opened. Seth On Wed, Jan 20, 2021 at 3:02 PM Michael Thomas <[email protected]> wrote: > > On 1/20/21 2:59 PM, Seth Blank wrote: > > Michael, please open a ticket. I think you're right and some consideration > around this is needed in the document. > > What about the https part? If it's not in scope I don't want to add noise. > > Mike > > > On Wed, Jan 20, 2021 at 2:56 PM Murray S. Kucherawy <[email protected]> > wrote: > >> 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 >> > > > -- > *Seth Blank* | VP, Standards and New Technologies > *e:* [email protected] > *p:* 415.273.8818 > > > This email and all data transmitted with it contains confidential and/or > proprietary information intended solely for the use of individual(s) > authorized to receive it. If you are not an intended and authorized > recipient you are hereby notified of any use, disclosure, copying or > distribution of the information included in this transmission is prohibited > and may be unlawful. Please immediately notify the sender by replying to > this email and then delete it from your system. > > _______________________________________________ > dmarc mailing [email protected]https://www.ietf.org/mailman/listinfo/dmarc > > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc > -- *Seth Blank* | VP, Standards and New Technologies *e:* [email protected] *p:* 415.273.8818 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system.
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
