On Thu, Aug 13, 2020 at 8:23 PM Murray S. Kucherawy <superu...@gmail.com> wrote:
> On Mon, Aug 10, 2020 at 12:05 PM Tim Wicinski <tjw.i...@gmail.com> wrote: > >> During IETF 108, the chairs realized that there was interest in Dave's >> RFC5322.Sender draft. >> >> This starts a Call for Adoption for draft-crocker-dmarc-sender >> >> The draft is available here: >> https://datatracker.ietf.org/doc/draft-crocker-dmarc-sender/ >> >> Currently, the draft is marked as "Standards Track". The chairs feel if >> the >> working group does adopt this, it should begin as "Experimental". If we >> start >> to see adoption of this work, this can be changed back to "Standards >> Track" before >> Working Group Last Call. Of course, we welcome input from the working >> group on this. >> >> Please review this draft to see if you think it is suitable for adoption, >> and >> send any comments to the list, clearly stating your view. >> >> Please also indicate if you are willing to contribute text, review, etc. >> >> This call for adoption ends: 24 August 2020 >> > > DISCUSS. > > (just kidding; +1 for adoption) > > -MSK, participating, except for the joke part, that was with full authority > > "DISCUSS" shouldn't really be a joke. draft-crocker-dmarc-sender suffers from a similar problem as PRA in the SenderId draft. There is no way to validate that the specific intermediary is authorized by the (From) domain originating the email through it's generic signalling that it authorizes intermediaries. This means that any source can emit a message claiming to be a legitimate intermediary just as any source could game PR to gain a neutral result. This raises a significant question as to the value of this proposed draft. It essentially reverts to depending on reputation as to whether the intermediary's assertions (I'm really really trustworthy) should be accepted. One could achieve similar outcomes using only reputation and local policy override of DMARC policy. The only way a scheme along the lines of the proposed one would be if the specific intermediary were authorized either through a seperate DKIM signing of a field (with the intermediary domain ) that would remaintact even if the DKIM signing of the entire message were broken by the (authorized) intermediary. The proposed approach is easily abusable by individuals with malicious intent. Michael Hammer
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
