On Thu 07/Oct/2021 15:58:55 +0200 Baptiste Carvello wrote:
(I'm trimming my own message severely to avoid overwhelming the list)
Trimming even more, but it's still too long...
Mailing list stem from a time where not everything had to be moderated
and sanitized. This old Internet with weak "editors" has served us well,
and though some people want it dead, not everybody has to agree.
Standards should stay neutral on this political matter.
Every now and then someone comes out saying that SMTP should be abandoned and
it is time to switch to a modern communication protocol. The usual analysis
considers that in the old Internet trust was granted to any peer. Email
authentication was retrofitted. It started with SPF, continued with DKIM, and
now we have DMARC. Every time, the attempt is watered by recognizing that only
a few mail messages really need authentication, while the vast majority of
traffic can continue as before. Yahoo's and others' coup d'etat brought us to
face DMARC in day to day email. And, a good deal of people believes that
p=none is only a first step toward p=reject.
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. […]
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.
The draft should be much clarified: I had understood it would use the
name alone by default, with some configuration possible for subscribed
users (N.B.: not every list is subscriber-only).
Still, you're only answering the *easy half* of my paragraph: the hard
part is the author's real contact address no more being accessible (with
"traditional" munging, you can at least try and guess it; with this
draft, you can't even).
The Author: header field seems to fit this need. IMHO, it is the author's
domain DKIM filter which should take the burden to duplicate the content of
From: into that new field. RFC 9057 allows MLMs to do that as well. The
semantic may differ accordingly, so perhaps the author's domain should sign
Author: in order to make it clear.
The alias is only useful if you are a subscriber (I suppose mailing
lists won't resend alien mail) and if it is still operating (any free
service expires eventually…)
Yes! The point is that having the MUA use Author: to implement "Reply to
author" will take an inordinate amount of time. Most users seem to be unable
to alter To:/From:/Subject: fields in the composition window. I even proposed
From: Marissa via List <[email protected]>
but then the user would have to actually remove it.
B) Mailing lists
1)
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?
It's incompatible with the existing usage patterns of mailing lists and
expectations of the end users, as informed by 40 years of "tradition".
Communication is people talking to people, not domains talking to
domains, so you have to take a broad view of backward compatibility when
a change leaks up to the UI.
Oh, I see. I'm always confused between incompatibilities which require
software updates versus those which require end user training.
In all cases, rewriting From: betters a list's deliverability.
In other words, it solves the problem DMARC introduced, at the expense
of forcing list users to learn new usage patterns. We should not expect
them to be grateful :-)
I read that mailing lists cover a negligible percentage of global email
traffic. That may explain why DMARC designers apparently overlooked MLMs.
Is there some kind of characterization of mailing list users which explains
their being a minority?
C) Now what
1)
I agree with Doug on lists not being automatically recognizable as such.
It depends for what. A message with a "List-Id" header purports to be a
mailing list message. If all you have to decide is whether to bounce a
rejected message or just trash it, why not take this affirmation at face
value?
There are several newsletters which sport List-Id: header fields. Some of them
are spam.
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.
The list is only the right place to report breakage if there is
something to fix on its side.
If the list rewrites From:, it has nothing more to fix. If it doesn't, it
won't be notified by DMARC reports of any breakage.
So let's rewind history: mailing lists worked for years and minded their
own business. Then some mail senders and some mail receivers both
implemented this new thing called DMARC, and list operators suddenly get
overwhelmed with bounces.
I'd say the DMARC-implementing senders and receivers collectively
triggered the breakage, and should get the reports and act on them. The
receiver is obviously aware of the messages they trash, the sender is
notified through DMARC Aggregate reports. The list operator doesn't need
to be bothered.
If DMARC takes root, MLMs who want to keep their job have to be bothered. It
is not their fault, but they have to arrange for it. They can do it in a
somehow interoperable way, e.g. aware of possible unwrapping, or carelessly
following the least resistance path.
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.
From: rewriting only "works" if you ignore the requirements of mailing
list users.
Also, requiring all mailing lists to comply with it suffers from your
FUSSP syndrome just as well. The only reason it currently seems easier
is because they alone have incentives to fix the situation, and DMARC
senders and receivers have none.
I never heard of alternatives like rejecting posts from authors whose domain
publishes strict policies being put in practice. Ignoring the problem
completely is also a risky option. Unless DMARC will be put aside, MLMs will
have to comply.
It may happen that Yahoo mailing list users switch to Gmail, and DMARC strict
policies become an exclusive feature of heavily abused domains. That's the way
many intended DMARC should always have been. If evolution goes that way, we'll
never know if strict authentication would have made spammers to feel
responsible of what they send.
If a sufficient proportion of DMARC senders and receivers implement an
ARC-based solution, mailing lists can remove the workarounds and the
remaining DMARC implementers will have a strong incentive to follow. Or,
alternatively, mailing list users will have an incentive to switch
providers.
Another way is to use Sender:
https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-sender-00
That I/D looked similar to Sender-ID. It was abandoned because people objected
that it would be enough to add an invisible header field to confer
deliverability to a phish formally from BANK.example. ARC provides exactly the
same functionality, except that one needs to add three fields, not just one.
Best
Ale
--
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
