Recipient domains determine what messages they will accept or reject.Fairness and precedence are not necessarily applicable.I suggest that the DMARC standards track be placed on hold for at least a year. It is not clear to me, from this group's membership, that DMARC implementers feel an urgent need for standard status, so a delay should be tolerable to them.A Mailing List Protection WG should be formed to develop his ideas into an informational or experimental RFC. Then that RFC can be promoted to see if it wins over any current users of DMARC Sent from my Verizon, Samsung Galaxy smartphone<div> </div><div> </div><!-- originalMessage --><div>-------- Original message --------</div><div>From: Dave Crocker <d...@dcrocker.net> </div><div>Date: 7/26/20 9:50 AM (GMT-05:00) </div><div>To: Brandon Long <bl...@google.com> </div><div>Cc: IETF DMARC WG <dmarc@ietf.org>, Dotzero <dotz...@gmail.com> </div><div>Subject: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations </div><div> </div>On 7/21/2020 1:42 PM, Brandon Long wrote: > Stricter validation is not an uncommon addition to protocols over the > last 45 years.
If there are examples of adding stricter validation in a way that essentially requires changing the semantics of the payload, in order for the payload to survive, I can't think of any. Not TLS, not DNSSec, not S/MIME or PGP. DMARC essentially enforces a semantic on the From: field as a handling identifier, rather than an author identifier. When activity that has a long history of semantic validity and a continued desire for operation is forced to break the denotational source of authoring information, in order to get the mail delivered, then we are in new territory. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
