I doubt that tbe end result is the right one, but you need to articulate
the transition process.
Your proposal requires that all commercial mail systems be changed so that
their DMARC-enabled clients can send this missing field. Simultaneously,
all mail filters must be rewritten to use the new algorithm.
How does that occur without spam getting through during the switch?
When will MLMs know that it is time to stop header munging?
On Jun 23, 2020 2:49 PM, Dave Crocker <dcroc...@gmail.com> wrote:Folks,
This note is partially triggered by Mike's note this morning, but isn't
specifically responding to it. Rather it tries to elaborate on a
premise I've been implying but haven't been explicating:
What if the rfc5322.Sender field were typically/always present?
Or at least, what if it were always present for domains publishing
DMARC records?
What if messages generally had Sender: fields, even when they are the
same as the email address of the From: field? So for such domains the
From: really would only be the author information and the Sender: would
be the operational handling/sending information.(*)
The thrust of my reference to making a separate Sender: field prevalent
is an assumption that the patterns of evaluating email addresses could
adapt to take advantage of the reliable distinction. For one thing, it
could clarify the nature of the information used for filtering.
Currently we conflate 'handling agent' (or 'transmission agent')
information with 'authoring agent' information.
This leads to statements about end-user effects that actually are
fundamentally wrong, even as the use of supposed author address
information is demonstrating filtering efficacy. What would happen if
filtering agents had an explicit distinction between 'author' and
'sender'?
It might be claimed that they already do, since the DKIM d= field refers
to a handling agent, rather than author, and is explicitly independent
of any other message address information.
So, why isn't it reasonable, for example, to have DMARC publish a record
declaring a requirement for a DKIM or SPF record, independent of From:
field alignment? That is, publish a record that says all mail by agents
of that domain is always authenticated?
It's because the signature needs to be tied to a field that is already
'interesting' and always present. Otherwise there is no way to know
what domain name to look for. In practical terms, the only available
choice has been From:. First, it certainly has an interesting semantic
-- but really semantic/s/ -- for the address, and second, it's always
present.
So... what if DMARC's semantic were really for the Sender: field? If a
message has no separate Sender: field, then of course the domain in the
From: field is used.
The would produce obvious possibilities:
From: someone@goodplace.example
Sender: someone@goodplace.example
and
From: somone@goodplace.example
Sender: some...@mlm.example.com
where there might be a dmarc record for mlm.example.com
The modification to DMARC would be "look for Sender: and if it isn't
present, look for From:.
Obviously, mlm.example.com might instead be badactor.example.com.
but we already have to deal with cousin domains, and DMARC does nothing
about them.
So if Sender: wouldn't be as useful as From:, why not?
d/
(*) Mike took exception to my using "processing" as a term for Sender:.
He's probably right and it might be worth some separate discussion to
make sure there is useful and precise language to cover what the
semantic of Sender: should/must represent. There is a continuing
problem in the industry that the word "sender" is used to cover all
sorts of agents, from author, to originating MTA, to Mediating MTA.
Should it be 'any agent that touches the message' or 'any agent the does
a sending operation of the message' or 'the specific agent the posts the
message into the mail handling system' or something else?
Note that for mail going through a mediator, there are at least
two entities qualifying for the 'posting' definition: The author's
originating MSA and the MLM's MSA.
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
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
