First let me make clear that (1) I do have influence on Mailman's position here but (2) I am not authoritative and (3) Mailman has no position yet. I'm discussing this and that and we'll see where my position and eventually Mailman's come out. So anything I say may be wrong (always check my logic ;-) and I may change my mind. :-)
Alessandro Vesely writes:
It is the MLM as a whole which has to conform, if it wishes to participate. Not the mailing list software.
If you mean the decision is list by list, conformance doesn't mean much -- the subscribers still need to learn the rules list by list, most of them won't know what "RFC 9999" conformance means, and other sites interacting with such a site will need to check the conformance of lists individually.
On the other hand, if you mean site-wide, if it were implemented in Mailman (and other software), conformance would be much more likely and much more likely to be site-wide.
I push ARC as the authentication method because that was the major objection to using Author: (the "simple" method in the old version.)
Yes, I agree, authentication is important, and ARC provides validation of the right data for some purposes. I'm not sure it "does what you want", but I do "want what it does".
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?
I don't think there's anything to symlink. In Mailman 3 all of this configuration information is in an RDBMS like PostgreSQL, and routing of posts and modification of messages (both bodies and headers).
I'm not clear how that would work. Would you expand?
- List-A@example.com has two subscribers: List-A-munge@example.com List-A-nomunge@example.com List-A-[no]munge accepts subscriptions according to site and list policy.
- List-A is configured not to allow other subscribers under any circumstances. List-A-[no]munge accept subscribers under the site and list policy.
- List-A-[no]munge refuse all posts, and advertise List-A as the destination for posts. List-A accepts posts according to site and list policy.
- List-A-munge gets From munging for all posts, List-A and List-A-nomunge never get From munging. (In theory List-A-munge could do munging only for p=reject posters, but always doing it probably makes it easier for subscribers to maintain their filters.)
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,
90% of the email users on the Internet are served by organizations that can afford comprehensive and reasonably accurate reputation databases and update algorithms. (Whether they do bother with accuracy is another question.) So I think it's reasonable to ask "how does a reputation database affect this feature" several times. For the rest of us, there are less sophisticated but still useful shared reputation databases (ie, the RBLs), and local databases such as SpamBayes can be useful.
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.
Everything is centripetal, because the only way we really know how to scale networks while maintaining discoverability is hierarchically. All reasonably decentralized networks have a (usually very expensive) centralized system at their foundation. I don't see ARC as being particularly biased toward centralization, just because powerful reputation systems are expensive. If anything, it's the opposite for the mailing list community, because it makes it easier for an independent list host construct and maintain its reputation, and should get it better treatment from those with reputation systems.
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 that's always out of scope. It doesn't hurt to add it, but technically its out of scope for an RFC.
- The no-munging method [...]
- Have an umbrella list with two subscribers, the twin lists. The twin lists would be configured to refuse subscriptions and posts from non-members.
Whether to refuse posts from non-members is independent of the no-munging protocol.
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.
This would require the MLM site to maintain a separate site. Otherwise you're spoofing a third party. Not good.
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,
This SHOULD is inappropriate, because the order of the chain is completely out of control of the ARC sealers. What matters is (1) an unbroken AR chain with all AAR showing a pass for authentication of the previous ARC set, (2) a valid DKIM signature on the received message from a trusted source, and (3) some trusted system (not necessarily i=1!) validates From alignment. (More details below.)
since indirect posts can be problematic when final receivers have not marked the preceding intermediate domains as trusted.
I don't think this is a practical problem in the case of mailing lists. In almost all cases[1], there is *one* DKIM break, and that is at the mailing list. If the MLM system finds a valid DKIM from the originating system on the incoming post, it can check From alignment and include the DMARC pass in its AAR. If at the final receiver, the MLM system's DKIM and ARC set validate and the MLM's ARC set says DMARC passed, then the only question about DKIM and DMARC is "do I trust the MLM?"
Note that from the point of view of ARC, the question of trust is only about the authentication of the post, that is, "did the mailbox in From send essentially the same content?" It doesn't help us decide whether the post is appropriate to distribute to the list. Either the sender or the MLM could be a spammer, or it could just be off-topic. The decision whether to trust the MLM's spam/virus filters is a different question, and I don't think it's affected by ARC, except to the extent that the MLM can be authenticated to the extent that the ARC chain is trusted, so if the MLM sends malcontent, they can't say, oh, that was spoofed.
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.
I don't understand this last sentence. You still have to mark the trusted hosts somehow. You can maintain a whitelist easily with
echo mailman-developers@python.org >> /etc/MTA/trusted-mailing-listsand use that list equally easily with no authentication or with ARC. ARC means you can trust the results more, though.
Setting the Author: header field is still useful to quickly check whether From: munging took place.
Agreed. I don't object to having Author for this purpose, I just don't think it helps with authentication.
Regards, Steve
Footnotes: [1] I have never heard of problems with DKIM breaks before or after the mailing list, only at the mailing list. Since From munging has been around in a couple of different forms since April 2014, I'm pretty sure that signatures broken before or after the mailing list would have been raised on one of the Mailman lists. I'm not saying it never happens, just that I'm sure it's very rare.