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
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
