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:
- The ARC method
This twin-list proposal doesn't depend specifically on ARC.
Right.
For each list with From: munging enabled, a participating MLM MUSTTo 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, MUSTThis "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 subscribersCurrently 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:
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