I cannot speak to IETF consensus, since I am new to that process and I seem to be an outlier already. Agency and signatures are well understood legal concepts. 3000 years ago, people sealed their letters with a signet ring stamped in warm clay. Signing technologies have changed in that time, but the principle has not. A courier is responsible for keeping the signed and sealed part of a message unaltered. Envelope marks are acceptable. A digital signature is supposed to provide non-repudiation. If I submit a signed message to a list processor, and the list processor voids the signature, it has given me verifiable repudiation, the opposite of what either sender or receiver want. A closed group on a single server can use whatever rules they choose to implement in that community. For example, a web forum operates on the rules of the forum operator. However, an open group using the email infrastructure has to work within the infrastructure it uses. In the email infrastructure, the recipient has to deal with fraud, and any recipient accommodation to "harmless" fraud facilitates the people who are doing "harmful" fraud to that recipient. There are some obvious use-cases for MTA changes to a message, and we would do well to document and address them. The first that comes to mind is MTA comment fields. - A list processor wants to add a comment indicating something about the list that sent it. - A spam filter wants to add a tag indicating that the message is suspicious, but not sufficiently suspicious to be blocked. IETF would do well to specify a mechanism for MTAs to add information which MUAs present to the user, while identifiying that that the information came from the MTA rather than the original sender. Another use-case is related to body sections. IETF only forwards plain text, while most email solutions send messages in HTML+Text. I assume that IETF also drops attachments. DKIM cannot handle this because it hashes the entire body. A signature system that signed each section individually would allow sections to be dropped, with notification to the user, without breaking the signatures on the other MIME types. DKIM was supposed to provide sender authentication when SPF was invalidated by forwarding, so DMARC said that the two techniques should be evaluated together. I am realizing that if SPF is invalidated, DKIM is probably invalidated as well, so we have no usable sender authentication technology. This may explain why so many products that I have examined lack support for DMARC or lack good exception mechanisms for SPF, DKIM, and DMARC. It seems that email needs something like "DNS Flag Day", where major players announce a date after which certain behaviors that will no longer be tolerated. But as others have said, IETF is not that organization, and the organization may not exist. More discouraged than ever, Doug Foster
---------------------------------------- From: "Dave Crocker" <[email protected]> Sent: Friday, May 31, 2019 12:41 AM To: [email protected] Cc: "IETF DMARC WG" <[email protected]> Subject: Re: [dmarc-ietf] Debugging and preventing DKIM failures- suggestion On 5/30/2019 7:49 PM, Douglas E. Foster wrote: > I rather hoped that IETF would be the poster-boy for list processing > done correctly. "Correctly"? A message to a list is 'delivered' to the list. As in, it goes to the specified addresse... the list. A message from a list has been re-posted by the list. There are no constraints on the changes that are permitted to a message, before it is re-posted. There are no specifications that limit or direct the behaviors of a list processor. Different groups want and probably need different behaviors by a list processor. Periodic efforts to create such constraints have failed. So while it would certainly make things easier to have list processors behave in a simple, consistent manner, there's ample evidence that ain't gonna happen. If you can link the 'correctly' you are suggesting, to some documented, community consensus, please cite it. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
