On Mon 21/Oct/2024 16:43:03 +0200 Dave Crocker via mailop wrote:
On 10/21/2024 4:39 AM, Alessandro Vesely via mailop wrote:
On Mon 21/Oct/2024 05:50:09 +0200 Dave Crocker wrote:
In other words, to get around DMARC fragility and false positive damage, an
intermediary must
1. Break DMARC, by changing the rfc5322.From address to be something other
than the original address
2. Break From semantics, since it no long has the address of the author,
3. Break any existing Reply-to semantics, so it no longer specifies an address
other than the author's, though that's what Reply-to was define to permit.
Collateral damage abounds.
Those changes can sometimes (not always) be undone, For your message I got:
"sometimes, not always" is a euphemism for "not subject to standardization or
reliable interpretation".
As such, I am not understanding how the observation aids discussion of my
comments.
Your comment recaps the well known mailing list problem. So, I though it would
be appropriate to recap what the proposed solutions are.
There have been various drafts around undoing MLM transformation. My one,
draft-vesely-dmarc-mlm-transform, is the only one implemented. The "not
always" part resulted after deploying. The other drafts seek reliability more
toughly, but won't be implemented. So this documents a non viable way to solve
the problem. (Yet, having that implementation slightly mitigates the breakage.)
DMARC has turned the From field into what the Sender field was intended to
provide; it now primarily serves to specify the handling platform. If the
author address survives in the From: field, that is merely a collateral
benefit, but not required.
Well, formally that's what SMTP specifies.
When making a claim about what it in a specification -- especially a large one
-- it is important to cite specific segments of text, so the reader can
evaluate the claim.
Sorry, I thought the citation was clear. The snippet I quoted was from
draft-ietf-emailcore-rfc5321bis-31, section 3.4.2.2. The current SMTP, RFC
5321, features almost the same text, that is: "Such mailing lists need to be
viewed as full MUAs, which accept a delivery and post a *new* message" (my
enhancement).
In this case, to keep things simple, SMTP does not discuss the
From/Sender/Reply-To header fields. The combination was introduced in RFC733,
for Arpanet mail, before Internet mail, and was carried over into RFC 822 and
its successors.
As for your claim that SMTP (or whatever) specifies the behaviors and semantics
that DMARC has produced, no it doesn't.
The closest thing in the specs that is relevant is allowing the Sender: field
to be absent if it is redundant with the From: field. This was a small
efficiency hack that now, 45 years later, is proving problematic because it
makes it easy to misunderstand that there are two separate semantics at work in
the From field.
Indeed, changing the header (except adding trace fields) and/or the body,
according to SMTP, is tantamount to creating a new message. So its content is
entirely at the mercy of the message creator. The semantics derived from
decades of mailing list experience is still not specified, AFAIK.
The Sender: field in particular was used in the Sender ID experiment and in
your draft, and considered not apt for authentication.
Even the new draft says that changes that involve more than the envelope
addresses "need to be viewed as MUAs that accept a message delivery and then
submit a new message for multiple recipients."
I am missing your point. How is this relevant to my comments?
There is a contrast between SMTP and DMARC. A couple of sections in dmarcbis
confirm that point by trying to limit usage of p=reject so as to be compliant.
At full DMARC capacity —that is, in an environment where all messages are
authenticated—, every sender will have to have p=reject and every receiver will
have to honor it. To reach that point, we have to specify forwarding, methinks.
/Forwarding/ is not specified.
I am also missing the import of this.
See previous paragraph.
Confirmed opt-in is a de-facto practice which does not let the receiver know
about the setting up of a new mail flow.
Confirmed opt-in has nothing to do with mail flows.
Why not? Isn't a mail flow a set of messages sharing similar characteristics?
So, when you add an address to a mailing list you are setting up a mail flow,
aren't you?
Confirmed opt-in is likely part of the forwarding specification.
If the recipient knew, it could trust the sender's ARC and pass those
messages with the original From:. However, I talked to Google people and
they consider it too complicated to manage users subscriptions.
ARC is not relevant to my comments.
I thought you commented about DMARC breakage in order to elicit a discussion
about the possible solutions. ARC is a tool that can be deployed for solving
the mailing list problem. In that sense, it is part of the recap you introduced.
Best
Ale
--
_______________________________________________
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
