On Tue, Jun 2, 2020 at 12:44 PM Jesse Thompson <jesse.thompson= 40wisc....@dmarc.ietf.org> wrote:
> I'm relaying these DMARC questions/concerns on behalf of an email admin at > another university. I quickly searched this list's archives for the Sender > header vs DMARC alignment issue and don't see much aside from a > conversation in May 2015. Is it worth further discussion and/or an issue > in Trac? I think I know the answer to the second concern, but I'll defer > to people more adept at explaining the nuance. > > See below... > > Thanks, > Jesse Thompson > UW-Madison > > " > I don't see on the list of issues the most fundamental problem of DMARC, > namely that it conflicts with RFC 5322 on the use of the From and Sender > header fields [1] and possibly with RFC 6326 as to the significance of DKIM > fail [2]. The former is the more serious problem. Making DMARC alignment > part of a standard for Internet messages requires a revision of RFC 5322. > I'd love to see this resolved. > > [1] > The "From:" field specifies the author(s) of the message, > that is, the mailbox(es) of the person(s) or system(s) responsible > for the writing of the message. The "Sender:" field specifies the > mailbox of the agent responsible for the actual transmission of the > message. > > [2] > signature verification failure does not force rejection of the message; > " > We went through this with SenderID and it's use of Sender in PRA. Back in the day I upset the folks at Microsoft responsible for evangelizing SenderID by sending emails to them using their name an email in the From field and myself in the Sender field. My emails would consistently get a neutral rating under SenderID because of how PRA worked. As part of the original DMARC team, the goal was to make clear whether the email was authorized by the domain being used, hence the reliance on SPF and DKIM. These are clearly under the domain owner/administrator's control to the extent they choose to exercise that control. There was much discussion in the community at the time to use thei= field to enable more granular signing. it never gained traction. Because the intent was to protect end users from fake emails purporting to be from (primarily) commercial domains such as financial institutions, greeting card companies, etc., the Sender field was not a significant issue. Also, when the Sender is in the same domain as the From, there is no DMARC issue. Michael Hammer If you really want to enable someone to send on your behalf then a) give them direct access to send from your account; b) give them your private DKIM signing key (which allows them to sign for any account in that domain or c) delegate a subdomain to them so they can generate their own SPF or DKIM records.
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
