On Tue, Jun 21, 2022 at 7:02 AM Bill Cole wrote: > Rewriting header and envelope addresses is as old as Sendmail. > > > I'm mystified by your distinction between rewriting the envelope sender > and "managing bounce addresses."
Since this has been a discussion of history, one used to be able to set Return-Path and Errors-To on lists, which is what we did. > Which was the point I was making: SPF does not cause problems with > mailing lists, because they use their own domains in envelope sender > addresses. This subtle distinction was lost on me. Thank you for pointing that out. When the big guns started enforcing DMARC/DKIM, we rewrote the From and the envelope sender, solving both problems. Before that, we didn't have to. > Because a "public trust system" is either impossible or at least > resembles an impossibility. I hope for the latter. > There's no universal agreement on the specific outline of acceptable > behavior regarding mail. We could still have a public trust system that didn't require everybody to agree on this concept. What needs to be known is to define publicly how to fix your (authenticated) reputation at any given ADMD. If you have a content (or otherwise) problem with a particular ADMD, the ADMD sends a response which requires you to show that you fixed the problem (whatever that is). This could server-to-server (e.g. unsubscribed user X) or possibly require human intervention, but either way, there would be a standard in place for identifying "you" and the meaning of "fix". If you continued bad behavior, they don't have to trust you. The problem today is that "you" is ill-defined and "fix" is even more poorly defined. While you can't define everything, with DKIM and ARC, "you" is defined for authorization but not authentication. A simple bidirectional challenge-response protocol using these keys would be sufficient for this. Publishing a "well-known" port for a "fix" server which allowed "you" to respond appropriately would also be a relatively easy step. It's a bit like greylisting in some sense, and maybe that approach (registration) could be part of the trust system, too. Thanks, Rob
_______________________________________________ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
