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 <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
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
