Instead of immediately deciding which ideas can and cannot work, I suggest that we create an extension mechanism for DMARC and then let the market decide. Perhaps someone will find traction for an idea that is useful to a subset of users even if it is not useful for every sender-receiver pair.
The extension mechanism could be as simple as an "add-ons=Y" clause in the DMARC record. If a receiver has implemented ANY add-on method, this flag tells him to check all of the options that he supports. Most likely this will require one or more additional DNS lookups to determine which add-on technique is supported by the sender. The result of those lookups will determine if the sender and the receiver support any of the same techniques. When there is a match on supported techniques, the logic for that technique is invoked. But when the flag is absent, no resources are wasted on checking add-on methods that can only apply to a subset of all messages. This approach separates the DMARC spec, which focuses on two specific authentication strategies, from add-on methods that invoke alternate authentication strategies, so that the DMARC specification can move forward. It leaves room for all of the ideas mentioned so far, and for those that have not yet been suggested. It also leaves room for a good-but-neglected idea to gain traction based on future events. The details of those other implementations can be determined by private agreement or by RFC. DF ---------------------------------------- From: Alessandro Vesely <ves...@tana.it> Sent: 8/21/20 4:58 AM To: dmarc@ietf.org Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list On Fri 21/Aug/2020 01:55:52 +0200 Dotzero wrote: > On Thursday, August 20, 2020, Jesse Thompson <jesse.thomp...@wisc.edu> wrote: >> On 8/20/20 4:00 PM, bl...@google.com wrote: >>> Neither atps or spf include are really designed for large scale usage >> >> That's my conclusion, as well. I don't want to authorize every potential >> MLM to use all addresses in all of our domains cart blanch, even if I would >> otherwise trust them (e.g. their purported ARC results). >> >> I *do* want to authorize our *own* MLM(s) to use our own domains for >> *internal* use... so I thought for a minute... maybe ATSP has merit for >> small scale usage, as an alternative to SPF include? Besides limiting the recourse to hashes, w.r.t ATPS my proposal provides for a rhswl zone which can be outsourced. >> But no, I don't know if any MLM has a way to check to see if they >> are authorized via any mechanism, so they will continue to munge >> the From header for our DMARC-enabled domains anyway. That is going to be true for /any/ method we devise now. From: rewriting is not going to stop on the next day. We must tune aggregate reports so that MLMs can tell if it's still necessary. It may take decades... still better than ∞. >> So, for this *internal* use case, maybe I'll just check the ARC >> result from the trusted MLM and replace the From header with the >> value of Reply-to/X-Original-From, and call it a day. Restoring From: at the MDA is certainly a good idea. However, the need to whitelist each MLM is not much viable for a number of operators. And, in case, I'd adopt John's broad brush: If I went so far as to whitelist the MLM, why should I take the burden to scrutinize the way it applied policies? It seems more sound to allow my recipients to see the same messages as every other subscriber. > This is why I proposed a tag that would have a value consisting of the > authorized intermediary domain. It would only be valid for that message. > Because the tag is signed separately from the rest of the message, it > should survive even if the intermediary modifies other parts of the > message. If the intermediary DKIM signs the modified message with their own > signature, that provides some assurance to the receiver. That was described on June 26, here: https://mailarchive.ietf.org/arch/msg/dmarc/wM97DmQ6-FEgMD7wkEKtk1PdBbU/ It requires modifying signer behavior. AIUI, the sender recognizes that one of the recipients is an allowed mailing list, and adds that tag to that copy of the message. It looks less outsourceable than an external whitelist. Let me call weak signature this concept. As it is very similar to dkim-conditional, either one or the other should be adopted. By contrast, a somehow limited Sender:, dkim-transform, Author:, as well as weak signatures can all be adopted concurrently. > I haven't seen enough favorable response to justify working on a detailed > submission to the group. I'm not an IETF standards wonk. I'd support weak signatures, in either embodiment. I don't think it needs to be linked to the Sender: field. Best Ale -- _______________________________________________ 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
