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-[no]munge accepts subscriptions according to site and list
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

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.


Mailman-Developers mailing list -- mailman-developers@python.org
To unsubscribe send an email to mailman-developers-le...@python.org
Mailman FAQ: https://wiki.list.org/x/AgA3

Security Policy: https://wiki.list.org/x/QIA9

Reply via email to