Alessandro Vesely writes: > It would also be possible to link DB tables,
No, it's not. It's all one row (IIRC). > or to define triggers that replicate insert/ update/ delete on a > number of tables/ fields. Which is exactly the complexity I don't want in Mailman if we can avoid it. Keep it to flat tables in approximately normal form. > The question is how much more insight than average list keeping > would be needed to do it. "Too much." :-) The simple "message per subscriber + per-subscription 'munge' flag" is just so much better. For example, there are at least three conceivable values: no munge, munge all, munge p=reject (and I think Mailman actually implements munge p>=quarantine as well!) This gets very tedious in the twin-list implementation. > Would this approach make sense with Mailman 2? The umbrella + twin lists approach is perfectly possible with Mailman 2, but the admin has to implement it themselves. We are not going to implement it or release it. > 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? There's a "sibling list" feature for exactly this purpose. > > 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? cost of 1 list X 3. > IMHO, it becomes overly complicated. So don't do it. Others will, however -- isn't that what "decentralization" is all about? -- and some of them are quite good at it. Why not take advantage of that to make at least some mail flows cleaner and more useful? > DMARC was thought so that From: bank.example can hardly be faked. Yes, and that's still true. > Allowing fuzzy overrides is much like getting back to content > analysis. Fuzzy overrides are not "allowed". They *happened*. Gmail did it from the get-go. RFC 8617 is recognition that it does happen, and a protocol that purports to improve the accuracy of overrides. > I'd mark as trusted only a few domains, based on personal knowledge. Have you analyzed your mail flows to see if there seem to be frequent messages with multiple DKIM breaks? AFAICS, in practice *you* as an individual will need to trust your mailing lists because that's the only place signatures are going to be invalidated, and you can demand everybody else has to pass DMARC. This is no different from before, except replay attacks via mailing lists are going to be harder. For large sites with many users with diverse mail flows, the benefits of both ARC and reputation systems are much larger. > 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!, ... That's not true. Bayesian filters work well for almost everyone. > > 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. They're *already* whitelisted by the small personal sites who trust it. The critical question is how fast are the large orgs going to learn to trust small ARC participants, because it's exactly those large orgs that are the root of all evil^Wer, most nondelivery problems that we small sites experience. ARC and DMARC are *not* targered at *us*, though if the large orgs use them effectively we will benefit. They're for large sites with hundreds of thousands (and sometimes billions) of users who are targeted by ransomeware hackers and national espionage agencies. > > 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. Yeah, I was in a hurry. Thing is, there are a lot of inexperienced folks out there who would just send mail from "bi...@whitehouse.gov" or something like that. :-) > 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). This is *Internet mail*. "NO REASON" is its slogan! But here's my personal use case: I use a Japanese telco as my home ISP but use my server at my employer as smarthost. My employer (research university) doesn't know or care, but they do intercept that mail at the firewall, and could reasonable ARC seal it. Then it goes to the MLM, which breaks the DKIM signature. So (1) as long as my DKIM signature is intact, which it is, the MLM should accept my post and add an AAR with dkim=passed; dmarc=passed, and (2) you don't need to trust my employer, you only need to trust the MLM (and of course since both my DKIM and my employer's DKIM break at the MLM, if you don't trust it, it doesn't matter if you trust my employer). > 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. I still think you're going to get pushback on the requirements language, but the analysis is complete and accurate. > > 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? Yes and no. Yes, the semantics are different, so having different attributes could provide more accurate assessments. But no, doing that means you're on the way to a full reputation system! ;-) _______________________________________________ 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
