On Mon, Aug 22, 2022 at 6:32 AM Barry Leiba <barryle...@computer.org> 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 > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
