The "Sender" vs "From" discussion reminds me of SenderID and its
companion RFC4407 protocol:
Purported Responsible Address (PRA)
https://tools.ietf.org/html/rfc4407
"This document defines a new identity associated with an e-mail
message, called the Purported Responsible Address (PRA), which is
determined by inspecting the header of the message. The PRA is
designed to be the entity that (according to the header) most recently
caused the message to be delivered."
Dave's proposal seems to suggest 5322.Sender would be the PRA of
interest and serve more useful than 5322.From for the purposes of
performing DKIM Policy lookups. If the 5322.Sender is missing, then
for backward compatibility, the fallback is 5322.From.
I can see engineering power if we can leverage the work already done
in this regard. Dave's refocus with Sender can be validated with the
PRA work. It will also offer a great benefit with another
SenderID/PRA companion RFC4405 SUBMITTER protocol.
SMTP Service Extension for Indicating the Responsible
Submitter of an E-Mail Message
https://tools.ietf.org/html/rfc4407
Designed for SenderID to be processed at SMTP (without needing the
payload) by passing the PRA to the SMTP client MAIL FROM command using
the SUBMITTER keyword:
C: MAIL FROM:<[email protected]> SUBMITTER={PRA}
The good news, there is running code using the PRA/SUBMITTER Protocol
and with 13+ years of empirical data, it showed:
PRA is 5322.From for direct mail
PRA is 5322.Sender for indirect mail.
I think Dave's proposal should get ample review.
However, the DKIM age-old problem still remains; how does the author
domain authorize all this? How does the author domain authorize the
PRA? In addition, what is 5322.Sender's relationship with the DKIM
signature signer domain? Is there some alignment questions?
There would now four (4) identities in the DMARC process model;
5321.MAIL FROM: Reverse path domain
5322.From: domain (the first one)
5322.Sender: domain
5322.DKIM-Signature Signer domain (d=)
Actually 5 if we want to throw the client domain name (EHLO/HELO) into
the pot.
While we can use the PRA for some "lookup," do we still need to tie it
or bind it with the 5322.From?"
There is the ATPS, TPA, the ingress conditional that can use to make
the bind which currently binds the signer domain with the author domain.
So those protocols will need to be updated as well.
--
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos
On 6/25/2020 7:22 PM, Scott Kitterman wrote:
On June 25, 2020 11:04:43 PM UTC, Dave Crocker <[email protected]> wrote:
On 6/25/2020 3:58 PM, Scott Kitterman wrote:
Why would I be expressing an interpretation of the charter that I
didn't think is correct?
That's not what i said.
I mean that you are asserting a requirement as if it were established,
based on your interpretation. the requirement is not established and,
of course, i believe it won't be.
Absent direction from the chairs, of course I'm going to operate on
the basis of my interpretation (although I think it's less
interpretation and more reading what's explicitly there, I'd imagine
you would view it differently).
The point is needing to be more tentative. Opinions are of course
fine. The state of being an opinion is transitive. It flows onto any
assertions made based on it.
I think the bar to convince me that it's okay to throw away aligning to 5322.From is in scope
for the working group is really high when the charter defines DMARC as "Domain-based
Message Authentication, Reporting & Conformance (DMARC) uses existing mail authentication
technologies (SPF and DKIM) to extend validation to the RFC5322.From field".
So far, no one has presented any arguments to suggest an alternative view is
correct. I think what I think and I don't feel any need to be disingenuous
about it.
That doesn't mean I won't change my mind later if someone makes a convincing
argument that an alternative view is correct. Don't confuse having a firm
opinion with being unwilling to consider alternative views.
Scott K
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
