On Sun, Aug 2, 2020 at 5:44 PM Douglas E. Foster < fost...@bayviewphysicians.com> wrote:
> Murray took server too literally. I have expressed before that a system > could do a sender authentication lookup on List-ID as easily as on From. > In this respect, it is similar to Dave's proposal, without the added > complexity of additional identifiers. So think "Registerd List-ID plus > DKIM signature (or SPF, but DKIM seems both sufficient and preferable.) > If we take "server" to mean a tuple made up of a List-ID value and a "d=" value from a validated DKIM signature, which I believe is what you're saying here, the first occurrence of this necessarily has no internal value (or history) attached to it. That means the operator has to develop meaning for it over time, which doesn't tell it how to handle the first N such messages. Err on the side of openness and you have a spam or attack vector; err on the side of defense and you irritate your users by denying them some list traffic until a reputation can develop. And it's probably actually a three-tuple, with the third part being the recipient. Otherwise, I could register (or trigger the auto-registration of) any two-tuple I want and thus intentionally let in my preferred list streams, good or bad, which affects every other user. Plus, you're trusting users to get this right. For a manual registration scheme, every time they get it wrong by entering the wrong data or failing to even do it at all, you've got a failure mode to deal with, usually in the form of user complaints which require other humans to resolve. That makes it relatively expensive. And finally, lists change once in a while, maybe to a new signing domain, maybe to a new name, maybe both. Every time that happens, the process has to start over. Naturally lists won't want to do this because of the sterling reputations they've developed, but the pain reappears whenever the process needs to be repeated for whatever reason. I'm not saying such a system can't or won't work. I'm also not saying I have a better idea. I am saying there's multi-faceted pain in every direction in this space, and this is no exception. Whatever path we choose to deploy here has to account for those choices and their side effects, and the ways they might be gamed. I am not sure what "Internet Scale" means to you. Most of the major > recipients have bulk mailer registration systems. It does not guarantee > whitelisting, but it tends to produce that effect. I have had occasion to > register with most of them. So "does not scale" is not obvious to me. > "Internet Scale" means millions or billions of users, like GMail or Yahoo or AOL or Microsoft have. Since they have the bulk of the inboxes, a solution needs to at least consider that size of use case, or explain why those cases don't need to be considered. I've never seen this manual registration process to which you refer. Where can I find it, for example, on GMail? Even more to the point, check out this link: > > https://blog.postmaster.verizonmedia.com/post/616023179026202624/increasing-relevance-performance-through-vto > > > Verizon appears to be offering a service (probably for extra cost) which > is based on: > (a) a well-defined mail stream from a known sender, and > (b) a mailbox user identifying that mail stream as subscribed, and > therefore desirable. > > It appears that the target senders are retailers who want to ensure that > their sale announcements are read before the sale is over. It is an > "Internet scale" application of the type of registration I was suggesting: > Well-identified senders, coupled with end-user endorsement, receive > preferred treatment. > Is there a technical description someplace of the mechanism behind what they're doing? As to the transparency question, it should be clear that there will be no > simple solution to the ML problem. > Indeed. [...] But the only way to establish an acceptable reputation is to either > register with the receiver directly, or register with the sender in a way > that the receiver will honor. > This needs to scale, from both ends: 1) If I as a new list operator want my list traffic to get accepted, how could I possibly go about registering with all (or even most) mailbox providers in a way they will trust? 2) If I as a mailbox provider want to give my users quality service and also spam filtering, what way can I offer list operators to identify themselves that can't be spoofed, and will only be exploited by good actors? Putting this burden on my users doesn't feel tenable. -MSK
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
