On 5/15/15 8:52 AM, Dave Crocker wrote: > 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. Dear Dave,
Also notice the attention to the Sender header field by section 7.1 of RFC5321 in the following statement: ,-- Efforts to make it more difficult for users to set envelope return path and header "From" fields to point to valid addresses other than their own are largely misguided: they frustrate legitimate applications in which mail is sent by one user on behalf of another, in which error (or normal) replies should be directed to a special address, or in which a single message is sent to multiple recipients on different hosts. (Systems that provide convenient ways for users to alter these header fields on a per-message basis should attempt to establish a primary and permanent mailbox address for the user so that Sender header fields within the message data can be generated sensibly.) '-- Operational practicality varies dramatically by domain based on the type of email handled. For transactional email, with some exceptions, policy based solely on the From can be operationally convenient. When handling a normal range of email configurations as typified for most ordinary users, restrictive policy based solely on the From header field domain will be highly disruptive of otherwise legitimate and properly formed messages often supporting important functions relied upon by a very large number of communities. Unfortunately, DMARC removed admonishments on limiting the types of email to be used by the domain asserting restrictive policies and simply notes in Section 10.5 incompatibilities when mediators such as mailing-lists are used. This appears to indicate DMARC proponents have entrenched into a view DMARC can force From header field munging and abandonment of RFC5322 defined roles and the functions defined by RFC5321, and submission practices defined by RFC4409. Rather than striking up the theme for Frozen, the theme for Jaws seems more appropriate as basic email specifications are crossed out in red. Without question, abuse monitoring represents a level of effort. Feedback provided by DMARC permits rapid and automatic identification of essential exceptions otherwise hidden without DMARC domain distribution of this information. Defending even simple url feed services that attract children as followers as well as various Ad feeds represent extremely difficult and serious challenges. A challenge greatly assisted by maintaining a type of informal federation. Larger providers are certainly less concerned about becoming blocked and may choose to ignore difficult aspects of their message distribution. Placing this effort onto recipients who lack necessary tools to rapidly identify abuse will cause a general erosion of security. It seems unimaginable recipients will disregard offers by the DMARC domain of authoritative threat related information. The authorization of those maintaining trusted resources provides an authoritative source of abuse related information approaching the level of a binary yes/no result. The DMARC domain remains the sole arbiter of reputation. Attempts to distribute this information within DKIM siglets by initial messages entails a similar data set but that can't be easily updated. Why not expand DMARC to include assertions of an offering of domain relationships within a single cache-able DNS transaction? Nothing else offers less overhead. Such a change can prevent the munging of From header fields or placement of otherwise valid and legitimate messages into spam folders. Of course, dmarc-wg can decide everyone wanting to use email must now use a new From header field designated specifically for that purpose to avoid the previously defined header field now laden with restrictive DMARC policies. https://tools.ietf.org/html/draft-otis-dmarc-escape-02 defines one such possibility. im-from = "IM-From:" (mailbox-list / address-list) CRLF address = mailbox / group group = display-name ":" [group-list] ";" [CFWS] mailbox = name-addr / addr-spec addr-spec = local-part "@" domain ["/" resourcepart] The resourcepart could be used to be compatible with XMPP. This element could be ignored when determining designated MTAs, but can isolate message sources to better identify the agent involved to better deal with any possible abuse. Regards, Douglas Otis _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
