Perhaps it should be the other way around. Addressing the mailing list problem was part of the prior milestone, which indicates its relative importance. ARC got us past the milestone but does not provide certainty for the list.operator. Your concept provides a reliable solution starting from the receiving participant and his domain. ATSP for Users could provide a reliable solution framework starting from the sending participant and his domain.
I don't think replacing the PSL has equal priority, and I think the problems created by our redesign are being underestimated. Doug Foster On Mon, May 1, 2023 at 6:52 AM Alessandro Vesely <[email protected]> wrote: > On Mon 01/May/2023 04:25:17 +0200 Emanuel Schorsch wrote: > > I want to ask about the "hollow victory" aspect and what would turn it > into a > > more meaningful victory. If fromHeader rewriting is the damage we want > to avoid > > it seems there's two options: > > 1) Have the mailingList make a decision based on what they know about > the > > evaluator. This would need some mechanism for evaluators to indicate > what trust > > techniques they accept. > > > Can do better than that. Have evaluators indicate under what conditions > they > accept whitelisting agreements. If the MLM can meet such conditions they > set > up whitelisting, for a specific recipient, of messages signed by the > mailing > list, even if they break DMARC (see below). > > However, this cannot be part of DMARCbis. > > > > 2) Have the mailingList rewrite the fromHeader but store the original > > fromHeader and propagate the necessary trust information so that > downstream > > evaluators can undo the rewriting. > > > > Given that currently many mailingList do fromHeader rewriting it seems > that #2 > > would allow gradual adoption and flexibility for experimentation over > time to > > see what trust methods work and allow downstream evaluators to make > > personalized decisions depending on the recipients trust preferences. > > > Been there, done that. For the message I'm replying to, I have: > > Authentication-Results: wmail.tana.it; > spf=pass smtp.mailfrom=ietf.org; > dkim=pass reason="Original-From: transformed" header.d=google.com; > dkim=pass (whitelisted) header.d=ietf.org > header.b=jAsjjtsp (ietf1); > dkim=fail (signature verification failed, whitelisted) header.d= > ietf.org > header.b=QuwLQGvz (ietf1) > > However, not all signatures can be verified. Mailman tries and preserve > most > header fields, but not all. For example, they rewrite MIME-Version: from > scratch and don't save the old one. So if a poster signs that field and > writes > it differently (e.g. with a comment) MLM transformation cannot be undone. > https://datatracker.ietf.org/doc/html/draft-vesely-dmarc-mlm-transform > > > > What are your thoughts? What would be needed for that to result in a > non-hollow > > victory? > > > I'll propose another draft, here or in the ART WG, more or less like so: > > * The mailing list sends a message to the subscriber domain requesting > permission to send mailing list messages that may fail DMARC checks. > > * The message explains that list messages will be properly authenticated > using > ARC, but may fail DMARC alignment checks because they are being forwarded > by > the mailing list server. > > * The subscriber domain verifies the request with the subscriber and, if > the > subscriber agrees to receive mailing list messages, provides a DMARC > override > specific for the mailing list server's domain and the recipient. > > * The DMARC override allows mailing list messages to bypass DMARC checks > and be > delivered to the subscriber's inbox, so the mailing list won't rewrite > From: in > messages to that subscriber. > > Additionally, it may be helpful to provide regular reports or updates to > the > domain's IT team, detailing any issues or incidents related to the mailing > list's email traffic. This can help establish a sense of trust and > accountability between the mailing list operator and the domain, and > demonstrate that the mailing list is actively monitoring and addressing > any > potential security concerns. > > That has to be discussed, but not in the DMARCbis context, otherwise > someone > will say it's mission creeping, someone else will escalate it to mission > gallop, an they'd be somewhat right that such discussion delays DMARCbis > publication. IOW, let's proceed step by step. > > > Best > Ale > -- > > > > > > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
