About this comment
If you teach users that "Joe User by Random Intermediary" is the same
as "Joe User", this expectation is doomed.
Based on the response to my previous post, "Trained User" is not a meaningful
concept, for purposes of this discussion. However, a user who subscribes to a
mailing list should be able to recognize its distinctive message
characteristics, so I think training is not a significant issue. I have had
fun looking at the different ways that IETF mailing list entries are presented
in my different MUAs.
More to the point:
I suggest that the "Mailing List Problem" is a problem that does not need to be
solved (and evidence suggests that it cannot be solved.) I can think of no
purpose served by a public mailing list, like this one, which is not be better
solved by a community forum website with user login. Even in its heyday, I
think mailing list subscribers were a narrow subset of email users, heavily
skewed toward Unix-oriented technology people. Solving the mailing list
problem seems like saying, "I want a secure and reliable way to order my
Walmart groceries using the text feature of my flip-phone." It is time for a
different technology.
There are other indirect mail scenarios that are problematic, but these seem
well understood and I do not see that any improvement is available. These
include:
DKIM (configured at the sender), SRS Encoding (configured at the forwarder),
and Trusted forwarder registration or another exception mechanism (configured
at the recipient filter). Incoming email filters have inadequacies when
looking backward on a forwarded message, but this mailing list is not concerned
with specifying the desired features of incoming mail filters.
DF
----------------------------------------
From: devel2...@baptiste-carvello.net
Sent: 6/13/20 8:04 AM
To: dmarc@ietf.org
Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list
problem
Hi,
I'm but a mere user, but I cannot let this be presented as an obvious or
consensual solution. Header munging is inadequate because:
1) It makes the wrong tradeoffs. DMARC started as a solution for a very
specific problem (phishing targetting high impact domains) and made
tradeoffs accordingly. Now that it is deployed as a general anti-spam
tool, the appropriate tradeoffs are different: most users are willing to
live with some degree of spam rather than have their communication
tampered with and their name associated with random intermediaries.
"Fait accompli" is not acceptable, even if you call it "de-facto standard".
2) It buys you nothing. As was discussed last week, DMARC by design
relies on the expectation that users (or their MUA's adress book) will
recognize legitimate From addresses. If you teach users that "Joe User
by Random Intermediary" is the same as "Joe User", this expectation is
doomed.
Cheers,
Baptiste
Le 12/06/2020 à 10:02, Alessandro Vesely a écrit :
> Hi all,
> I'm sorry I didn't queue to talk yesterday. After so many months without
> speaking one word of English, I really didn't feel like...
>
>
> *Why ARC cannot solve the mailing list problem*
> ===============================================
>
> Assume all mailing lists in the world duly did ARC. Somewhat
> science-fictitious, given that some of them are not even able to add valid
> DKIM
> signatures. Let's hypothesize they all did ARC, anyway. Would the mailing
> list problem be solved? No, because recipients cannot blindly accept DMARC
> failures just because there is an ARC-chain claiming authenticity. Doing so
> would completely defeat DMARC, because ARC chains can be forged.
>
> In order to safely override a reject or quarantine policy based on ARC, a
> receiver needs a complete list of legitimate mailing lists. Conversely, having
> such a list, a receiver can override DMARC failures also based on DKIM or SPF
> authentication. ARC adds nothing to the mailing list problem. (However, huge
> mailbox providers do have a complete list of legitimate MTAs. That's where ARC
> is useful, AIUI.)
>
>
> *From rewriting is the real thing*
> ==================================
>
> Rewriting From: is the de-facto standard. In a (science-fictitious) scenario
> where all mailing lists rewrite the From: header field, DMARC would just work
> smoothly.
>
> Hence, we have to specify an acceptable way to rewrite From:.
>
>
> I'd have said so.
>
> Best
> Ale
>
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
