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

[Baptiste Carvello <[e-mail]>]

Hi,

(I'm trimming my own message severely to avoid overwhelming the list)

Le 06/10/2021 à 20:22, Alessandro Vesely a écrit :
> 
>> A) The From field
>> 1) 
>> a)
> 
> A list claims some responsibility for the message as well.

[…]
>> b)
> 
> 
> Right.  Yet, posters do trust the MLM operator somewhat.

Traditionally, these have been a very weak "some", and a weak "somewhat".

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.

>> 2)
> 
> 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.

"via" is better than anything else. Still, that's too much emphasis on
what I consider a technical intermediary.

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

In the use case I know best (Open Source development mailing lists),
there are good reasons to contact posters, even years after the fact
(say you have inquiries about an old design decision). An yes,
mailing-list archives often outlive bug/patch trackers.

In the worst case, aliases can lead to communication hijacking. That's
my point B3), which you didn't answer either. Typically the provider of
an Open Source mailing list goes "evil", either with aggressive
monetizing a la sourceforge, or by trying to turn the product proprietary.

> Which unwrapping are you talking about?  I developed an unwrapping
> mechanism[*] to be used by the server, not the MUA. […]

Yes, that's it, thanks for the pointers. I didn't remember it only kicks
in when modifications can be undone. Then, it doesn't create a loophole
in DMARC checks, but is only useful for part of the problem (how big a
part, your draft doesn't say).

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

>> 2)
>> Doug's note on authors' privacy addresses a kind of mailing lists. 
> IETF's lists are public and publicly archived.  Other lists preserve
> anonymity.

That's not my point. My point is, in the lists I know, preserving
anonymity is a bug, not a feature. Hiding the author's real address
prevents some useful communication patterns. Granted, addresses in
messages bring SPAM, but users already know how to protect themselves.

I'm not denying this is a judgment call which you may well disagree
with. Standards work however should only consider facts: accessibility
of the author's real address is by design, and it has valid use cases.

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

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

> 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. […]

That would be a possible variant, but what's the point of producing a
bounce, if it's going to be ignored anyway?

I understand the a priori reluctance to trash a message with no
feedback, but here, the case is well known by now, and bounces only
cause harm (not just delisting, but also DOSing the list operators).

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

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.

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

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.

Cheers,
Baptiste