On 9/16/2022 7:35 PM, Brandon Long via mailop wrote:
For 30 years, we allowed mailing lists to modify messages and take
partial "ownership" of them (the mailing list gets the
* Small factual nit: Networked email was 50 years old, last year.
Mailing lists appeared almost immediately after that. Say 45 years ago.
* "Allowed" establishes an odd and false view of Internet application
development and use, since there was never any authority forcing
creation or use of any Internet app. The term is meaningful only if
there had been such an authority. Saying "allowed" for a process
that was and remains entirely community driven does not make much
sense, though it arguably sets the stage for the more-recent
experience of change imposed by operators with extraordinary market
leverage. As we have seen.
* "Taking partial ownership" is odd and ambiguous phrasing. So let's
be straightforward and specific:
o An author posts a message to a mailing list address. The author
and the originating platform "own" the message.
o The message is delivered to that address.
o The mailing list formulates a brand new message, based on the
one it received, but changed in whatever ways the mailing list
feels like doing. In the same sense as such control and choice
applied to the author originally formulating the message they
posted.
o The mailing list 'owns' all of its choices and it owns the
resulting message.
o In the interest of the a higher-level membership overlay
semantic, the mailing list typically will post a message that
sustains a participant sense of and end-to-end -- ie, author to
reader -- integration. That is, it stitches together two,
independent email posting/delivery segments, to produce a
seamless user experience. The author-created rfc5322.From
header field has pretty much always been part of that choice.
* The mailing list posts this new message, typically with and address
related to the mailing list in the rfc5321.Mail From command, but
not always.
Let's stress the key point a bit more:
* The mailing list fully 'owns' the message it posts.
* The mailing list might or might not choose to facilitate a
participant experience (a version of UX) that creates a sense of
integration and utility that connects the author posting with the
mailing list posting.
bounces), without
modifying who the message was "from". When digital signatures were
introduced and then linking them to the sender, it made that untenable...
Again, let's be very careful here.
* Digital signatures did not create a problem. As already noted,
DKIM's d= was specified so that the linked domain name did not have
to be related to any other domain name or email address in the
message. And a DKIM failure was explicit that the result must be the
same as having no DKIM present.
* DMARC created the linkage to the From: header field. When DMARC was
created, it was clear it would create a problem for third-party
uses, such as mailing list. However DMARC development was explicitly
for a business-to-consumer use that would not involve such third
parties.
* Much later, some very large email platforms unilaterally chose to
expand DMARC's use to consumer-to-consumer and therefore,
inevitably, created the collateral damage of breaking third-party
use that had been in place for 40 years.
but the reason we added the signature and linkage was because of bad
actors, and the number of "we always did it this way" things that have
fallen to our fight with bad actors has been quite large.
Forgive me, but a version of that line of comment has been quite common
in some email professional circles. It primarily serves to cut short
serious discussion. It's much too facile, and typically ignores
unintended consequences. And as formulated above, I think it's probably
wrong.
* Specifically, anti-abuse work certainly has made operating an email
platform a lot harder. However, the effect on end-users has
generally been hassle, but no alteration in email semantics or use.
* DMARC changed that. The unilateral decision by email platform
operators to extend DMARC's use to c-c mail broke the From: field
semantic for third-party operations.
* DMARC semantics really requires knowledge of an operator, not an
author. This is what makes it reasonable to ignore the From:
<addr-spec> (left-hand-side) value.
* In effect, DMARC has turned the From: field semantics into the
Sender: field semantics. (Note that DomainKeys was tied to Sender:,
not From:.) For RFC 733, we allowed the Sender: field to be omitted
if the value was the same as for the From: field.
While it took 45 years to teach the lesson, it has become a stark
example of the basic problem of creating a design that conflates semantics.
The Author: field is now available to have no semantic other than the
address of the author, and to permit survival across mailing lists in
the face of DMARC. There has been some suggestion that it can't be
useful because bad actors will just go and subvert it. Again, a facile
comment, offered without any technical substantiation. I suspect it is
also wrong.
The convention now used by mailing lists, to get around the breakage
caused by DMARC is to break the From: field's utility, by replacing the
author name and address with a mailing list address. This affects
recipient UX by making messages from the same author be processed as if
from a different author. It also can break Reply-To usage, if the
author had created one.
* Curiously also note that in practical terms, this breaks DMARC.
Quite easily. The recipient sees a message they think is from the
purported author and the purported author's domain, but the DMARC
test is not performed.
So, while AOL & Yahoo were the vanguard for mass consumer providers,
the problems were already being experienced by many corporate domains
before that, and even more since.
The issue is not that the abuse was/is not real but that the method of
responding to it was chosen in a manner that externalized the problem to
innocent third-parties, breaking what they had been doing for 40 years.
It would be good not to be cavalier about this, just because those
experiencing the collateral damage are not our users.
d/
_______________________________________________
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
