Alessandro Vesely writes:

 > Internet-Draft             MLM Transformations            September 2022
 > 
 > 
 > 3.  The ARC method

This twin-list proposal doesn't depend specifically on ARC.  Any
subscriber who thinks they know better than the DMARC protocol can
choose to ignore the DMARC policy, and they would benefit from the
twin-list proposal.  For example, if the un-authenticated received
chain indicates that the MLM received the post directly from an
author not in the MLM's domain, and I trust the MLM, and its DKIM
signature is valid, I would accept that mail and ignore DMARC.  Of
course if the MLM host provides a sealed AAR field, that's much
better, but the one-hop-to-MLM scenario is very strong evidence of
authenticity if the MLM is very trustworthy.

 >     For each list with From: munging enabled, a participating MLM MUST

To be honest, I don't think that Mailman would be willing to conform
to this.  I haven't seen the rest of your draft, but this section is
really more of an Informative/BCP RFC than Standards Track.  That is,
this is an option that list creators can already exercise with the
cooperation of the list owners, so there's no need to impose
requirements on MLMs.

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.  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.  A per-subscriber option for From munging would be simpler to
develop and maintain.

 >     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.  On the other hand, doing
all this cleanly is more complicated than implementing recipient-
controlled From munging.

 >                                                               Subscribers
 >     who think that their mailbox provider runs a suitably configured
 >     DMARC filter can subscribe to the twin list.  Users subscribed to
 >     both lists receive double messages until they unsubscribe or suspend
 >     delivery from one of them.

Recipient-controlled From-munging would also prevent unnecessary
double messages.  It's just cleaner.

This next paragraph seems unrelated to recipient controls on From
munging.  It seems pretty obvious, and is ARC-specific.
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.  Have you considered reviving that document?

 >     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.

 >     MLMs which in turn trust third party domains, such that they override
 >     DMARC failures in posted messages, MUST

This "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 subscribers

Currently most sites (MTAs) operate content filters and blacklists,
but not whitelists, and the MLMs trust their sites.  I don't see why
that needs to change with ARC.  Either way, I'm pretty sure those most
sites would be unwilling to publish those lists and keep them up-to-
date, and the MLMs don't have them.

Note that it's quite rare for the MLM to trust anybody under current
conditions.  Most mail flows to MLMs are direct, and for MLMs that
host open subscription lists, they can be from anywhere.  So MLMs
expect their sites to provide content filtering and sender
authentication, not trust (reputation) algorithms, and the MLMs don't
participate in maintaining any of these facilities.

 >                                     when they announce the creation of the
 >     twin list, and on subsequent modifications.  How users can query the
 >     list of domains trusted by their mailbox providers is beyond the
 >     scope of this document.  Anyway, all the domains possibly trusted by
 >     the list MUST be trusted by the user's MTA as well, and by any
 >     subsequent MTA in case of forwarding.

The recipient MTA has the whole chain, it can decide whether it wants
to trust any individual signer in the chain.  If it doesn't, it can
choose to consider the whole chain invalid.  As a subscriber,
checking your own whitelist or blacklist is very cheap compared to the
process of validating the ARC chain.

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.  I think you should provide rationales
for these recommendations, and for a MUST they have to be very
persuasive, I think.

Sincere regards,
Steve
_______________________________________________
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

Reply via email to