Re: [dmarc-ietf] DMARC-Compliant Mailing Lists

[Alessandro Vesely <[e-mail]>]

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 <[e-mail]>

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
--