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
