Although I re-raised the change log issue as part of the auto-forward problem, I am hoping that it will have significant benefit to the mailing list community also.
Of the three types of content changes that I proposed, the easiest to specify and get implemented is the first type, where the mediator only adds content, adds a change log indicating the additions, and signs the result. I am hoping and assuming that if mailing lists have freedom to add their branding to the subject and body, most lists would not need to make more complex changes. The signed change log would allow participating recipients to identify the signed additions added by the list or other mediator, while also identifying the signed original after the list additions are virtually removed. Once the additions and the original are reliably identified to a source domain, suspicion of spoofing is no longer a concern. Each chunk of content can be evaluated based on the reputation of the verified source domain and the specifics of the content. Nested additions are possible. Each new signature adds an entry to a verification stack. Any change can be removed, virtually or actually, by reversing the change at each level, working backwards from last to first. In practice, the stack is expected to be short. To prevent malicious misuse, the specification should put a small limit on the number of layers in the stack. Just as importantly, I believe it solves the problem of letting the list know whether From rewriting is necessary or not. I argue that there is no information-leakage risk associated with a domain publishing a DNS entry that says "This domain understands multi-author documents of type 1". This type of flag says nothing about what the domain will do with any particular message with multiple authorship. The recipient domain will have the option of passing the entire message, stripping the wrapper and passing the original, or blocking the whole thing. But it will not be blocking a message because it does not understand the message's actual identity, which is the cause of our current problem. Once a list knows that its identity will not be misjudged, it gains the freedom to assume that its content will be judge fairly, so "From" rewriting should not be necessary when sending to domains that have published this flag. Because this approach adds confidence rather than risk, I am hopeful that even AOL would be willing to implement support for it. The more complex changes, edits and deletions, require a more complex specification and more complex code. That level of specification will be needed to provide a solution to spam filters that do URL rewriting. But that complexity can wait for another day while we try to get a level 1 change log accepted. John, I am hoping that you find some opportunity here. Do you? Doug Foster ---------------------------------------- From: "John Levine" <jo...@taugh.com> Sent: 9/3/20 6:44 PM To: dmarc@ietf.org Subject: Re: [dmarc-ietf] AutoForward problems In article <767e2dcc-e87c-1e90-2f86-486e51a3c...@wisc.edu>, Jesse Thompson <jesse.thomp...@wisc.edu> wrote: >I realize that John's message in the other thread probably wasn't referencing >auto-forwarding, but I think his point >dovetails to the auto-forwarding issue: > >> As always, as I hope we all remember DMARC alignment doesn't mean not spam, >> and you still do all of the stuff you do to sort your mail. ... As you say, it's the same problem, it's what people see as the same message but with changes that fail with current authentication schemes. >a) It assumes that the domain owner has the ability and desire to authorize >every potential forwarder, even though >auto-forwarding is a user-level decision. It's not the domain owner, it's more likely the MTA deciding what signatures to apply. >c) Selectively allowing forwarding at the user level is difficult because >users are gonna do what they wanna do (you >try telling faculty they can't forward). It's not the case that all >enterprises want to prohibit all of their users >from auto-forwarding (even though that's the answer you may get if you survey >the CISO community) Yeah. The likely damage from allowing wisc.edu to forward seems pretty low, the damage from outlook.com or gmail.com considerably more. R's, John -- Regards, John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly _______________________________________________ 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
