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

[Scott Kitterman <[e-mail]>]

I think you have gotten yourself side tracked.

The problem with DMARC and mailing lists is that receivers doing DMARC checks 
can't (absent a list of mailing lists) reliably distinguish DMARC fail due to 
normal mailing list processing and DMARC fail due to abusive behavior.  To 
mitigate this issue, a number of mailing lists (this one included) have taken 
measures so that list mail will pass DMARC checks at the receiver.  These 
measures have been a net negative for mailing list usability.

Mailing list managers can (and probably should) include DMARC in how they 
manage abusive postings to their lists, but that's not any kind of a special 
case for DMARC.

Scott K

On Saturday, April 8, 2023 7:16:05 AM EDT Alessandro Vesely wrote:
> Identifier rewrite affects the leg from MLM to subscriber.  Email security
> in the leg from poster to MLM is completely ignored by the draft, although
> MLMs constitutes a major concern.
> 
> We joyfully rely on traditional techniques to counter potential attacks,
> estimating that there is no reason to adopt cryptographic stuff to secure
> email.
> 
> Water we talking about?
> 
> 
> Best
> Ale
> 
> On Sat 08/Apr/2023 01:54:21 +0200 Douglas Foster wrote:
> > 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
> > 
> > _______________________________________________
> > dmarc mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dmarc
> 
> _______________________________________________
> dmarc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmarc