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
