On Mon, Aug 22, 2022 at 5:43 PM John R. Levine <[email protected]> wrote:
> On Mon, 22 Aug 2022, Wei Chuang wrote: > > I agree with the OP's premise that there needs to be a better > > authentication method that works with mailing lists. ... > > Google seems pretty enthusiastic about ARC. > > Since large mail systems already know where the mailing lists are, I asked > why not just skip DMARC checking on list mail. The answer was that lists > leak a lot of spam since many do very weak filtering, checking only that > the From: address is a subscriber. The point of ARC is to package up the > authentication history of a message so the final recipient can > retroactively do the filtering that the previous stages didn't. If you > look back at the ARC chain and see that a message was aligned when it > arrived at a list, which is easy to do, that greatly reduces the chances > that the message is spam. > > I wrote up a proposal for conditional signatures, which lets a sender put > a weak DKIM signature on a message that is only valid if it's also signed > by a specificed second signer, which would be the list. The original > signature just covers a few headers that the list is unlikely to change, > but it lets the message continue to be DMARC aligned after a list modifies > it. The ARC-ists didn't like it because it requires the original sender > to know who's going to re-sign a message, while ARC only looks backward. > > https://datatracker.ietf.org/doc/draft-levine-dkim-conditional/ I like the concept of the sender specifying the forwarding path that this proposal introduces. That idea can provide authentication and I believe resist replay attacks. I think this proposal would be more powerful if built into a framework like ARC and its ARC sets that can help it generalize describing forwarding through arbitrary many hops. > I don't think ARC is wonderful but I would be surprised if we could come > up with anything better, and doubly surprised if large mail operators like > Microsoft and Google who are already doing ARC trials would be interested. > I can't speak for my employer, but I think it's a good idea to come up with something better. The currently deployed authentication approaches DKIM and SPF that DMARC depends upon are showing their age, and have well known issues. In fact those well known issues such as DKIM replay, may make the conditions ripe for making improvements and justifying changes. -Wei > > Regards, > John Levine, [email protected], Primary Perpetrator of "The Internet for > Dummies", > Please consider the environment before reading this e-mail. https://jl.ly >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
