On Tue 05/Oct/2021 16:17:28 +0200 Baptiste Carvello wrote:
another season, another "From rewriting" proposal.
Doug's emphasis on aliases tends to give that impression. Otherwise it can
finally be a much needed attempt at formalizing the old, known From: rewriting.
A) The From field
=================
0) Unless I missed something, changing the semantics of RFC5322.From,
even just for mailing lists, is way off charter for this group.
1) The From field semantics are important not just for interoperability
with software systems, but also for "interoperability" with us *humans*,
which makes them especially hard to change :-) This human meaning is
twofold:
a) the "friendly From" conveys *authorship*, that is the (possibly
pseudonymal) identity of an *natural person* who claims credit and
accepts responsibility for the content.
A list claims some responsibility for the message as well.
A corporate entity such as a domain is *not* an author. And whatever the
"moderation" mechanism, a censor is just that, and will never be an
author either.
Right. They are publishers.
b) the address part provides a *contact point* for the above-defined
author, that must be as much as possible *stable* and under the control
of an entity *trusted by the author*.
Right. Yet, posters do trust the MLM operator somewhat.
2) All proposed "From rewriting" mechanisms fail at least one of the
above requirements. The traditional mechanism blurs the authorship, by
introducing a false sense of *affiliation*. This message is authored by
"Baptiste Carvello", not "IETF" or even "Baptiste Carvello by IETF". I
demand full credit, and I'm sure IETF happily lets me bear full
responsibility.
The usual rewriting is "Baptiste Carvello *via* IETF". It is shorter than MS's
"on behalf of", and hence better. The draft should cover this detail, IMHO.
Any mechanism that rewrites the address alone gives a wrong idea of the
contact point and thus possibly "hijacks" communication attempts. The
present proposal is especially egregious in that is does so without any
hint to the reader. If this happened to me, I would feel like I'm
subject to identity theft, sorry to say.
The "via IETF" or similar wording /is/ a hint. It is both a hint to the user
and a disambiguator for automated address books. This too should be mentioned
in the draft.
In fact, I lied, the "unwrapping" mechanism could meet both
requirements. Except that it is vaporware that no MUA has expressed
interest in implementing. And that for all practical purposes, it would
be equivalent to disabling DMARC for mailing-list traffic. Quite a
loophole, right?
Which unwrapping are you talking about? I developed an unwrapping mechanism[*]
to be used by the server, not the MUA. It works for posters who sign the
fields recommended by RFC 6376; that is, for example, not signing Content-Type:
and MIME-Version:. The receiving server replaces the munged From: with
Munged-From: and restores the original value of From:.
[*]
https://datatracker.ietf.org/doc/html/draft-vesely-dmarc-mlm-transform
http://www.tana.it/sw/zdkimfilter/zdkimfilter.html#mlmtrans
B) Mailing lists
================
1) Again, I question the process of redefining the operating principles
of mailing lists in a forum where neither mailing-list operators, nor
developers of mailing-list systems or even MUAs are represented. This
seems like a recipe for "solving" the wrong problem.
There used to be MLM developers on this list. Perhaps they unsubscribed due to
lots of traffic which does not concern mailing lists. Maybe it is a good idea
to send them a note. I sent one to Mailman-Developer.
Fragmenting the ecosystem by creating a new incompatible "blessed by
DMARC" kind of mailing list is of course worse than everything.
Why is that incompatible?
2) Specifically, the present proposal fails to take into account that
mailing lists are fundamentally different from "closed-group
communication systems", not by deficiency, but by *design*.
Interoperability with direct e-mail, including the possibility to
privately reply to the author (or to temporarily invite non-members by
just CC-ing them), is a necessary feature, not a "security hazard" to be
fixed.
Doug's note on authors' privacy addresses a kind of mailing lists. IETF's
lists are public and publicly archived. Other lists preserve anonymity.
In all cases, rewriting From: betters a list's deliverability.
C) Now what
===========
So what's my solution? Well I recognize it's not easy, but a first step
could be to mandate that, in the case of DMARC FAIL and p=reject, a
message coming in from a mailing list (with a List-Id header) must not
be bounced, but *ignored*. The rationale is twofold:
1) Bounces produce no useful result whatsoever, as they never reach back
to the originating domain. All they can do is have the recipient users
delisted.
I agree with Doug on lists not being automatically recognizable as such.
An alternative would be that MLM don't delist when the rejection message text
contains "DMARC". I know this is horrible, but there will never be a dedicated
5xx code for that. Of course, enabling From: rewriting is easier and cleaner.
2) DMARC incorporates its own reporting mechanism, which goes to the
right place.
The right place is the list, and it is reached if From: is rewritten.
That's the same logic that has always been in place for bounce addresses,
except that From: is visible to recipients. OTOH, DMARC chose that field
exactly for its visibility.
Once DMARC-compliant receivers do this, mailing list operators can
remove their workarounds and happily get out of the way.
Requiring all SMTP servers to comply is as weak as the paradigmatic FUSSP[†].
ARC suffers a similar syndrome. In comparison, From: rewriting works
out-of-the-box.
[†]
https://www.rhyolite.com/anti-spam/you-might-be.html#senior-IETF-member-5
Best
Ale
--
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
