On Tuesday, June 23, 2020 2:49:11 PM EDT Dave Crocker 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: [email protected] > Sender: [email protected] > > and > > From: [email protected] > Sender: [email protected] > > 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?
I've tried to follow this thread. I've no idea where to start to comment, so I went back to the beginning. I would encourage people to review the working group charter. I think dumping 5322.From and aligning to something else is well outside of it. Not saying we couldn't recharter, but I'm skeptical of the value of this entire thread. I wasn't there at the creation of DMARC, but it seems likely that 5322.From alignment wasn't picked at random. I don't think any amount of post-facto sophistry on IETF mailing lists will make that not true. Before we even think about alternatives, I'd like to hear from someone who was involved in the original effort explain the rationale for alignment to 5322.From and see a discussion on why that original rationale is now wrong (imagine I explain Chesterton's Fence here). Also, why an email address at all (base on my reading of the thread)? If some of the assertions being made are accurate, any random opaque identifier would do just as well. Scott K _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
