On Tue 13/Sep/2022 10:14:12 +0200 Stephen J. Turnbull wrote:
Alessandro Vesely writes:
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).
It would also be possible to link DB tables, or to define triggers that
replicate insert/ update/ delete on a number of tables/ fields. The question
is how much more insight than average list keeping would be needed to do it.
Would this approach make sense with Mailman 2?
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.
If the site policy is to accept posts from subscribers, it needs to inspect the
union of sub-lists subscriber sets. How could that be accomplished?
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.)
How difficult is that to set up?
I saw some lists deploying a home-brewed From: munging tool. In that case they
can control it directly.
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.
IMHO, it becomes overly complicated. Domain-based reputation is already fuzzy,
and for giant organizations it becomes unmeaningful —they're just too big to
block. Now, start gaming all possible combinations of domains. Replaying a
modified message is all too easy, and ARC can be ambiguous about who modified
what in a message. Yes, you could feed a neural network with that. Will it be
reliable?
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.
DMARC was thought so that From: bank.example can hardly be faked. Allowing
fuzzy overrides is much like getting back to content analysis. I'd mark as
trusted only a few domains, based on personal knowledge.
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.
It is not the cost. To have a global knowledge of the Internet you need to
have a user base that is statistically relevant with respect to the global
population. That is, you have to be Google, or Microsoft, or Yahoo!, ...
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.
Yes. However, I think that a list that experiments non-munging will be
whitelisted sooner by small, personal sites who trust it than by large orgs
computing its reputation.
3. The no-munging method
[...]
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.
It can be a dummy subdomain, a few lines in a zone file. I'll change that line
to "from a (sub)domain having p=reject", to have it more apparent.
Otherwise you're spoofing a third party. Not good.
Yeah, you'd have to ask permission to do that.
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.
Hm... a list SHOULD reject posts arriving with an ARC chain, valid or not.
Shouldn't it? I see no reasons to post indirectly (except for internal
list-to-list flows which don't need ARC seals).
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?"
You're right, I simplified too much. Changed that paragraph as follows:
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 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. In the unusual
case where the first ARC set is not by the MLM itself, it is REQUIRED
that an aligned DKIM signature be reported as pass by the MLM's ARC-
Authentication-Results:. That certifies that the message was
essentially intact when it reached the MLM. So the result can be
overridden when the MLM domain and any successive domain in the ARC
chain are marked as trusted.
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
(Cannot authenticate the local part.)
and use that list equally easily with no authentication or with ARC.
In theory, ARC was developed as a tool for overriding DMARC failures. Does it
make sense to have trust marks for ARC distinguished from generic whitelisting
flags?
ARC means you can trust the results more, though.
At least, more specifically.
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
