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?
1. lis...@example.com has two subscribers:
list-a-mu...@example.com
list-a-nomu...@example.com
List-A-[no]munge accepts subscriptions according to site and list
policy.
2. List-A is configured not to allow other subscribers under any
circumstances. List-A-[no]munge accept subscribers under the site
and list policy.
3. 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.
4. 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.
> 3. 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-lists
and 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.
_______________________________________________
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
