Alex,
I agree with a suggestion to have a separate document, a great
starting point is to update the ATPS RFC document. However, DMARCbis
MUST open up the door for it and address the potential new security
issues with From Rewrite.
1) Address the MUST NOT p=reject with a new small section, a few
paragraphs citing the basic non-compliance issues with legacy MLS/MLM
verifiers of not following DMARC policy and instead creating a new
potential security threat which may required a security threat section
or add it to the current "Display Attack" security section. I don't
believe we can get by this by saying it will "never happen."
2) Update section 4.4.3 Extended Tag Extensions to update the door up
to 3rd party authorization, ATPS and possibly others.
Thanks
--
HLS
On 5/1/2023 9:49 AM, Brotman, Alex wrote:
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
--
Hector Santos,
https://santronics.com
https://winserver.com
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
