On 5/14/2015 11:27 PM, Terry Zink wrote: >> The Sender header field when present has been defined for decades >> to represent the sending agent! > > Maybe, maybe not.
Sorry, but there isn't much maybe about it. The definition in the spec has been clear since the construct was invented, in 1977. /Usage/ has varied quite a bit, as with so much of email, with implementations re-purposing the field in various ways, thereby effectively defeating useful interoperability. And 'display' of the field is an entirely separate issue. Commentary about DMARC usually does cite 'display' as the essential requirement, which drives selection of the From field. IMO it continues to be a significantly misleading point, since end-user viewing of the From field is largely irrelevant to any real-world efficacy. This appears to be an indelicate point to raise, since it's being consistently ignored as discussions about DMARC continue (everywhere, not just here.) On the other hand, the rfc5322.From field is the only field with a content-related identifier that is /always/ present. Hence, a receiving filtering engine has a place that it always can always look, for a claim of authorship. By its nature, a mechanism like DMARC must begin with an identifier selected by the receiving filtering engine. Hence, there must (always) be an identifier reliably associated with the message. Its semantics must pertain to something semantically interesting. DMARC chose "content authorship", which is pretty obviously reasonable. With that claimed content responsibility, the engine can proceed with an analysis that relates the identifier to a reputation. One aspect of reputation is "is the identifier authorized for use?" DMARC answers that question. One could imagine a "handling responsibility" as being a reasonable alternative choice, too, but it's much weaker. Worse, it invites a problematic disconnect between content responsibility and handling responsibility, which thereby invites gaming the system. Choosing content responsibility is therefore much more appealing, albeit simplistic in a way that causes problems with the entirely legitimate scenarios that the community has been seeing. In particular, DMARC requires very tight coupling between content and handling responsibility, which differs from many, long-standing, legitimate scenarios. Choosing a properly-available Sender: field creates a much better semantic, in terms of pointing to the responsible operational agent. But it is not an operationally practical choice. The problem is that when that identifier is different from the content identifier, we have the task of figuring out whether the identity in the Sender: field is 'authorized' to operate on behalf of the identity in the From: field.[*] d/ [*] In case folk miss the point, the Sender identifier is /always/ present, even when the Sender: field is not. If this isn't clear to anyone, I encourage re-reading Section 3.4.2 of RFC 5322. -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
