Re: [dmarc-ietf] THIS IS ABUSE (it might be)

[Douglas Foster <[e-mail]>]

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 <[e-mail]> wrote:

>
>
> On April 7, 2023 6:43:33 PM UTC, Alessandro Vesely <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmarc
>