If an ARC chain with SPF PASS demonstrates that a list post is legitimate, it only does so because the evaluator is testing alignment (exact match) between the domain reported in the ARC results and the domain of the FROM address on the message. This is the DMARC verification algorithm, without the burden of a DMARC policy which is not relevant in this case.
We can conclude that: (a) lists which test SPF and create ARC results are desirous of being authenticated, and (b) evaluators who use ARC results in this way are also desirous of verifying authentication, because (c) the sender, the list, the evaluator, and the recipient all benefit when trust is increased by verification. So we have a non-policy implementation in the wild, based on ARC, but this committee wants to shut it down because it "is not DMARC". Why? (Remember that this last draft says MUST NOT attempt validation when the policy is not found.) DF On Mon, Aug 22, 2022 at 5:38 PM Wei Chuang <[email protected]> wrote: > > > On Mon, Aug 22, 2022 at 6:32 AM Barry Leiba <[email protected]> > wrote: > >> > Mailing lists are supposed to be a closed group. This means that >> posts should only be accepted if they are verifiably >> > from the subscriber indicated in the RFC5322.From address. This >> requirement means that a list needs a mechanism >> > for verifying the RFC5322.From address, and the mechanism needs to be >> applicable to 100% of the accepted >> > subscriber base. >> >> None of this is true in general. >> >> Some mailing lists operate so that only subscribers can post. Many do >> not. Even those that do generally do not insist on authentication. >> Some will use DMARC policy to determine what the purported From >> domain's policy is. Some do not. >> >> > At present, we have only one official mechanism for verification of >> RFC5322.From, which is DMARC. However, DMARC >> > is currently limited to domains that publish a DMARC policy, and this >> is a small subset of all potential subscriber domains. >> >> Because that's what DMARC is designed for. >> >> > DMARC actually creates a bizarre situation: >> >> DMARC does not create a bizarre situation. Internet email is >> inherently an unauthenticated thing. DMARC, along with authentication >> mechanisms (currently SPF and DKIM), addresses that point in the >> manner for which it was designed. DMARC was not designed to address >> it for cases where domains have not chosen to publish DMARC policies. >> >> I believe we have been through this multiple times and that working >> group consensus is against you on it. The working group does not want >> to extend DMARC beyond that design point. >> >> Barry >> >> > I agree with the OP's premise that there needs to be a better > authentication method that works with mailing lists. Stating the obvious > for many, but an important contributor to the lack of DMARC adoption, is > the difficulty in supporting mailing lists and other forwarding flows that > may modify the message which affects deliverability. Some may say that > DKIM is the right solution for forwarding flow, but message modification > breaks DKIM. Another limitation is that DKIM is susceptible to replay > attacks that make its results suspect. Yet at the same time DMARC provides > valuabling signaling about how to authenticate the originator which we lose > due to lack of adoption. I agree with the OP that there should be work on > a new authentication algorithm (or significantly improving existing ones) > that DMARC can then use in its policy framework. I'll write up some > concepts and send it out to the DKIM list (it was suggested that was a good > venue for the proposals, likely due to the charter issues mentioned here). > It will start off with DKIM replay mitigations, but hopefully work towards > better support for mailing lists. > > -Wei > > >> _______________________________________________ >> dmarc mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/dmarc >> >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
