This sounds like a separate document to me. (yes, I see Ale's draft below) And IMO, I don't think we should hold up DMARCbis for that work.
-- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast > -----Original Message----- > From: dmarc <dmarc-boun...@ietf.org> On Behalf Of Hector Santos > Sent: Monday, May 1, 2023 9:26 AM > To: dmarc@ietf.org > Subject: Re: [dmarc-ietf] Add MLS/MLM subscription/submissions controls to > DMARCbis > > On 5/1/2023 6:51 AM, Alessandro Vesely wrote: > > > > 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://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draf > > t-vesely-dmarc-mlm-transform__;!!CQl3mcHX2A!DfPhD9QIFk5QZaU- > JPkz748sZC > > > QtLXqL1FIxGonW_xDwc9pXdioEnY546GZUnzjzSNW1BdDF27VjLabqZaB5XtMgrS > WZ9HPP > > m2s$ > > > > And this was my result for your message, separating lines for easier > reading: > > Authentication-Results: dkim.winserver.com; > dkim=pass header.d=ietf.org header.s=ietf1 header.i=ietf.org; > adsp=none author.d=tana.it signer.d=ietf.org; > dmarc=fail policy=none author.d=tana.it signer.d=ietf.org (unauthorized > signer); > > dkim=pass header.d=ietf.org header.s=ietf1 header.i=ietf.org; > adsp=none author.d=tana.it signer.d=ietf.org; > dmarc=fail policy=none author.d=tana.it signer.d=ietf.org (unauthorized > signer); > > dkim=fail (DKIM_BAD_SYNTAX) header.d=none header.s=none header.i=none; > adsp=dkim-fail author.d=tana.it signer.d=; > dmarc=dkim-fail policy=none author.d=tana.it signer.d= (unauthorized > signer); > > dkim=fail (DKIM_BODY_HASH_MISMATCH) header.d=tana.it header.s=delta > header.i=tana.it; > adsp=dkim-fail author.d=tana.it signer.d=tana.it; > dmarc=dkim-fail policy=none author.d=tana.it signer.d=tana.it > (originating signer); > > Four signatures were added to your submission and the only one that counts is > the top one, the last one added. > > It failed DMARC because tana.it did not authorized ietf.org. You can > easily resolve this by adding atps=y to your DMARC record: > > v=DMARC1; p=none; atps=y; rua=mailto:dmarca...@tana.it; > ruf=mailto:dmarcf...@tana.it; > > and add an ATPS sub-domain record authorizing ietf.org in your dana.it > zone: > > pq6xadozsi47rluiq5yohg2hy3mvjyoo._atps TXT ("v=atps01; d=ietf.org;") > > Do that and all ATPS compliant verifiers should show a DMARC=pass: > > Authentication-Results: dkim.winserver.com; > dkim=pass header.d=ietf.org header.s=ietf1 header.i=ietf.org; > adsp=none author.d=tana.it signer.d=ietf.org; > dmarc=pass policy=none author.d=tana.it signer.d=ietf.org (ATPS signer); > > > For a short list of signers, I updated my DMARC evaluator to also support ASL > "Authorized Signer List" to avoid the extra ATPS record. > So doing this will work across my evaluator for smaller scale mail senders > > v=DMARC1; p=none; atps=y; asl=ietf.org; rua=mailto:dmarca...@tana.it; > ruf=mailto:dmarcf...@tana.it; > > > This will skip atps=y because asl=ietf.org was satisfied. It was show > how it was authorized: > > dmarc=pass policy=none author.d=tana.it signer.d=ietf.org (ASL signer); > > > Any ATPS or ASL idea will give us the author-defined trust of ietf.org > as a 3rd party signer. > > That said, keeping with the suggestion DMARCBis should add MLS/MLM > semantics, I believe when the Receiver is receiving mail for a > MLS/MLM, it should have the following updated modern consideration > for a MLS/MLM: > > 1) It should honor policy first, by check for restrictive domains > > 2) It should honor the domain restrictive policy to avoid creating new > security problems and avoid delivery problems. This means to > implement subscription and submission controls. DMARCbis should pass > the buck back to the restrictive domain who must deal with user's > needs or not. > > 3) It should check if the submission's author domain authorizes the > MLM signing domain by finding a ATPS record, if so.... > > 3.1) it can continue as the 3rd party signer and also keep the From as > is, unchanged, or > > 3.2) it can also consider to rewrite. If rewrite is performed, the > signing domain should have a security that does not allow any Display > Attack Replays with the now altered 5322.From identity. > > > -- > Hector Santos, > https://urldefense.com/v3/__https://santronics.com__;!!CQl3mcHX2A!DfPhD9 > QIFk5QZaU- > JPkz748sZCQtLXqL1FIxGonW_xDwc9pXdioEnY546GZUnzjzSNW1BdDF27VjLabqZa > B5XtMgrSWZ3guWaPw$ > https://urldefense.com/v3/__https://winserver.com__;!!CQl3mcHX2A!DfPhD9Q > IFk5QZaU- > JPkz748sZCQtLXqL1FIxGonW_xDwc9pXdioEnY546GZUnzjzSNW1BdDF27VjLabqZa > B5XtMgrSWZOlLgxbE$ > > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc__;! > !CQl3mcHX2A!DfPhD9QIFk5QZaU- > JPkz748sZCQtLXqL1FIxGonW_xDwc9pXdioEnY546GZUnzjzSNW1BdDF27VjLabqZa > B5XtMgrSWZiFT7qwo$ _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
