Hi Steve,
thanks for your precious insights.
Some comments inline and a new version:
On Sat 10/Sep/2022 10:41:21 +0200 Stephen J. Turnbull wrote:
Alessandro Vesely writes:
3. The ARC method
This twin-list proposal doesn't depend specifically on ARC.
Right.
For each list with From: munging enabled, a participating MLM MUST
To be honest, I don't think that Mailman would be willing to conform
to this.
It is the MLM as a whole which has to conform, if it wishes to participate.
Not the mailing list software.
I haven't seen the rest of your draft, but this section is
really more of an Informative/BCP RFC than Standards Track.
Experimental, actually.
The old version is here:
https://datatracker.ietf.org/doc/draft-vesely-dmarc-mlm-transform/
If this option gets traction (ie, some vocal fans, I don't ask for a
huge number), then I think Mailman would be willing, and would prefer,
to go all the way to recipient-controlled From-munging as you
originally suggested.
Should find a list wishing to experiment with it. I'm going to ask again to
IETF's Dispatch list when the new method is published in the draft.
I push ARC as the authentication method because that was the major objection to
using Author: (the "simple" method in the old version.)
Maintaining synchronization of configurations of two lists will be tedious
for the admin, or involve relatively complicated coding if we arrange to
automatically mirror configuration changes.
Couldn't symlink most stuff?
A per-subscriber option for From munging would be simpler to develop and
maintain.
Sure. That was the first idea.
configure a twin list with From: munging disabled. Both lists have
the same posting address, but separate subscriber lists.
I don't think having the same same posting address is likely to work.
Most MLMs probably won't implement at all, because list creators can
do it for themselves by having an umbrella list with two subscribers,
the twin lists. The twin lists would be configured to refuse
subscriptions and posts from non-members.
I'm not clear how that would work. Would you expand?
Recipient-controlled From-munging would also prevent unnecessary
double messages. It's just cleaner.
Yes.
https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-arc-usage-09
would be the natural home but it's expired, so it doesn't do any harm
to have it in your draft.
What I dislike of that document is its considering the availability of a global
reputation system as a widespread feature of all mail servers, while only the
known giants actually have one. In that respect, ARC is a centripetal
protocol, which is why I've been opposing it until this attempt.
Have you considered reviving that document?
No.
DMARC local policy overrides is one of the use cases that [RFC8617]
provides for ARC. It requires that a DMARC filter be configured to
accept the authentication assessments provided by a verified ARC
chain when all of the domains involved are marked as trusted. In
that case, the filter overrides DMARC policy and acts as if the
current Authentication-Results: were the ARC-Authentication-Results:
(AAR:) of the first ARC set (i=1). Normally, a MLM SHOULD apply
DMARC policy on message arrival, so the first AAR: is expected to
have dmarc=pass.
This paragraph also seems unrelated to recipient controls on From
munging, and is not ARC-specific.
It describes the mechanism by which a receiver accepts dmarc=fail using ARC.
(W.r.t. other papers, I add that the domains have to be marked as trusted,
which would act as a simplified reputation system.)
MLMs which in turn trust third party domains, such that they override
DMARC failures in posted messages, MUST
This "MUST" isn't going to work. The MLM software can't ensure this,
and MLM operators will do as they please.
communicate the list of trusted domains to subscribers
Currently most sites (MTAs) operate content filters and blacklists,
but not whitelists, and the MLMs trust their sites.
Right.
Anyway, I think individual subscribers aren't going to be making those
decisions, and won't want to unless they're the kind of person who
wants to run their own MTA, I think. This issue it discussed from
several angles in the I-D linked above, and their conclusion is always
the same: reputation maintenance is hard, and very site-specific, so
no recommendations in the I-D.
Should I add that it's out of scope to speculate how users can convince their
mailbox provider to trust/ whitelist a given MLM?
I think you should provide rationales for these recommendations, and for a
MUST they have to be very persuasive, I think.
Right.
And here's the new text:
3. The no-munging method
For each list with From: munging enabled, a participating MLM MUST
configure the possibility to have From: munging disabled. Depending
on the mailing list software used, a MLM can devise various methods
to accomplish the task:
* Create a twin list by symbolic links of most configuration files,
except the subscriber lists. Both lists thus have the same
posting address. Subscribers who think that their mailbox
provider accepts dmarc=fail from the MLM domain can subscribe to
the non-munging list. Users subscribed to both lists receive
double messages until they unsubscribe or suspend delivery from
one of them.
* Have an umbrella list with two subscribers, the twin lists. The
twin lists would be configured to refuse subscriptions and posts
from non-members.
* Have a per-subscriber option for From: munging. This is the
simplest and cleanest possibility, but requires a mailing list
software with this specific feature.
Before allowing subscription to a non-munging list, a MLM MAY test
that a recipient effectively receives its messages by sending a test
message with a broken signature from a domain having p=reject.
DMARC local policy override is one of the use cases that [RFC8617]
provides for ARC. It says that a DMARC filter can be configured to
accept the authentication assessments provided by a verified ARC
chain when all of the domains involved are marked as trusted.
Accepting the assessments means that the filter acts as if the
current Authentication-Results: were the ARC-Authentication-Results:
certified by the first ARC set, the one with i=1. The first ARC set
SHOULD be by the MLM itself, since indirect posts can be problematic
when final receivers have not marked the preceding intermediate
domains as trusted.
To produce an ARC set, a MLM's MTA performs SPF, DKIM and DMARC
checks upon receiving a message from the author's domain. The
results are saved in Authentication-Results: fields marked with the
MLM's domain, while making sure that no spoofs exist. The ARC filter
uses those fields to produce ARC-Authentication-Results: at the time
when it seals the message, which is the last step before the message
leaves the MLM domain.
ARC is not the only means by which a receiver can accept messages
which fail DMARC. Simply whitelisting the MLM domain, authenticated
by SPF or DKIM would suffice. The extra information that ARC brings
can serve for final receivers to evaluate MLM's filtering and compute
author's reputation. However, even MTAs that lack such sophisticated
reputation mechanisms can find ARC filters more convenient to set up,
as that is exactly their function.
Setting the Author: header field is still useful to quickly check
whether From: munging took place.
Best
Ale
_______________________________________________
Mailman-Developers mailing list -- mailman-developers@python.org
To unsubscribe send an email to mailman-developers-le...@python.org
https://mail.python.org/mailman3/lists/mailman-developers.python.org/
Mailman FAQ: https://wiki.list.org/x/AgA3
Security Policy: https://wiki.list.org/x/QIA9
