Scott's approach solves our longest-running argument, but not in the way that I expected. We can embrace his approach with a single Security Consideration to this effect:
"Mailing lists are frequently characterized by operating practices that depend on security through obscurity rather than Sender Authentication. Identifier rewrite may be used as necessary to evade detection of weak Sender Authentication practices. While exceptions doubtless exist, determining the trustworthiness of messages from any particular mailing list is difficult, and beyond the scope of this document. Participation risk should be taken into account when subscribing to a mailing list and accepting incoming messages from a list." However, this type of truthfulness does not seem to be what the charter document intended. Doug Foster On Fri, Apr 7, 2023 at 4:24 PM Scott Kitterman <skl...@kitterman.com> wrote: > > > On April 7, 2023 6:43:33 PM UTC, Alessandro Vesely <ves...@tana.it> wrote: > >It is going to be problematic to kick off someone who impersonates > different users. What do you do, block IP numbers? > > > >We keep on saying that mailing list have worked this way for decades. > Sure. And email in general has been working for decades before the need to > use authentication arose. So we can bet that people using MLs is highly > selected and well behaved... but is that true? Wouldn't a jester be able > to completely disrupt our work by heavily repeating impersonations to the > point that we'll be forced to restrict to Github tools to discuss our > drafts? I wouldn't bet... > > > >Some time ago I proposed a p=mlm-validate[*] telling receivers to reject > on failure only if they are a mailing list or similar forwarder. I thought > that would cause minimal disruption since such kind of posts most of the > times reach destination in one hop —akin to transactional stuff— and a > poster who gets a bounce can quickly retry. Such kind of tool would > eliminate impersonation chances. > > > >An obvious truth is that we cannot publish a successful protocol if we > ourselves see no reason to make any use of it. > > To the extent managing mailing list subscriber abuse is a problem, it's > not a DMARC problem. > > The IETF has had problems with sock puppets before and managed to address > them. > > Scott K > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
