Re: [dmarc-ietf] Gaining Legitimacy

["Murray S. Kucherawy" <[e-mail]>]

Replying to something almost two weeks old, apologies:

On Tue, Apr 18, 2023 at 7:10 PM Douglas Foster <
[e-mail]> wrote:

> When John says that list members plead their case, but their pleas are
> dismissed unsympathetically, it is evidence that mailing lists have a
> legitimacy problem.   As with many social issues, there are extremes:  AOL
> has unmoveably chosen security over list access.  The EDU community has
> chosen list access over perceived security benefits.   In the middle are
> people who might be convinced, but need convincing.   These are the people
> that should be the focus of effort by mailing list advocates.
>

The first sentence here contains a presumption that mailing lists are under
some obligation to prove their legitimacy.  This perhaps underscores the
chasm between the two perspectives.


> As an administrator of a business email system, I find myself in that
> middle ground.   So here are the areas where I would like to be convinced:
>
>    1. Why is it necessary for mailing lists, in general, to modify
>    content?   RFC 7960 needed a companion document on this topic,   When I
>    read 7960, I was unmoved because my thought was, "Intermediaries should not
>    be modifying content in the first place."    There must be others who have
>    the same response.   I doubt that RFC 7960 changed any attitudes, because
>    it never addressed the "why" behind the problem.
>
> Because consumers of mailing lists expect them to.  Users like the Subject
tags and the footers and the MIME rewriting and the whatever-else mutations
subscribers have come to rely on for (it is not an exaggeration when I say)
decades.  They have developed automations around them (sorting, filtering,
etc.).  These features have evolved over many years and are now pretty
typical, to the point where a list that doesn't do those things would be an
outlier.  The mutations have not been standardized, however, probably
because nobody has ever felt a need to do so, and some are probably
specific to particular implementations.  And there's little need to specify
them openly; they are all just text and MIME mutations that are fully
compatible with whatever transport and storage are applied and the display
software that ultimately consumes them.

I feel compelled to repeat the same refrain you've heard before: Mailing
lists have been around for a long time, and none of this mattered.  DKIM
appeared early this century, and suddenly there was a problem.

Paragraph renumbering is automatic, sorry...

>
>    1. Even if I become convinced, in concept, that SOME mailing lists
>    need to make SOME content changes, I would not conclude that ANY mailing
>    list must be allowed to make ANY change, without limit.   Before embracing
>    a particular list, I would want to know the particulars of what changes
>    that list makes, and why those changes are necessary to the success of that
>    list.   Isn't that reasonable?   Are there any industry norms for this type
>    of disclosure?    If not, why not?   If there are norms, why am I unable to
>    find such information for this list?   For this forum, I don't know what
>    attachments are allowed, whether posts are subject to malware scanning,
>    whether TinyURLs and their equivalents are allowed, or anything else
>    related to participation security.  I just checked the link at the bottom
>    of every message, and it contained nothing about these topics.
>
> I don't think anyone is arguing that absolutely any change is allowed, or
should be.  There's a relatively small number of mutations that are
common.  We could probably write them all down; in fact, I think back far
enough in this list's archive, I took a run at doing so.  But they are in
some cases hard to describe, and they can be applied in varying
combinations.  And since we're talking about DKIM, two implementations that
differ by a byte produce different results.

Note that this is squarely the problem that the DKIM transforms drafts were
trying to address.

I think this is probably the first time that there has been a demand made
that a subscriber should know a priori how messages to that list might be
mutated before distribution.  There are no industry norms of this type of
which I am aware, probably for the same reason I gave above.  If such
standards came into existence today, what would we expect people to do with
them?  What would you do with them?  What could we hope automated systems
could do with them?

>
>    1. Assuming that the first two objections are overcome, the last one
>    remains critical.   Acceptance of broken signatures will mean that I
>    delegate responsibility for sender authentication from myself to the list
>    server.   Can the list under discussion be trusted to ensure that both
>    MailFrom and From are free of deception?   Given my assumption that we are
>    talking about closed lists, this should be feasible.    Ale's abuse
>    demonstration was a deal breaker for me, because it demonstrated that this
>    list cannot be trusted with delegated responsibility for
>    sender authentication.    What will be done to restore my trust in this
>    list?  What can be done to ensure that trustworthy sender authentication is
>    the industry norm, rather than the exception?   When I can trust the list
>    to authenticate every post, I don't need to detect and parse an ARC set on
>    every message.   If I can only trust messages with DMARC PASS in an ARC
>    Set, then I will never be able to accept more than a subset of all messages
>    sent to me by a list server.
>
> There is, to my knowledge, no standard way to establish the trust you're
talking about.  Today, this is left to the realm of reputation and
judgement.


> As much as I hear the felt pain of mailing list advocates, I find the list
> industry to be woefully deficient on all three of these topics, and I see
> no movement to address any of the three.   If list advocates want to
> increase legitimacy with people in the middle ground, these issues need to
> be addressed.    Without it, I do not believe your language choice between
> "MUST NOT", "SHOULD NOT", and "should not" will make any difference.
>

Once again, we're placing the burden of proof here on the list implementers
and operators.  I would like to hear an explanation as to why that's where
the burden belongs.  Maybe that's right and maybe it's not, but I've yet to
see a convincing argument.  Otherwise, I'm left with the notion of an
exploratory force already set in its ways arriving in heavily populated
foreign lands and demanding the inhabitants explain themselves.

Until that happens, what I see is an irresistible force and an immovable
object, which leaves us with an obligation to document the problems we've
been unable to solve and not assign culpability.

-MSK, participating