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.
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.
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.
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?
/Forwarding/ is not specified.
I am also missing the import of this.
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.
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.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
_______________________________________________
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
