On Nov 25, 2014, at 2:49 AM, Stephen J. Turnbull <[email protected]> wrote:
> Douglas Otis writes: > >> Rather than issuing click through agreements to in essence say "All >> your email must represent direct transactions from the provider." >> they could offer users a friendly SMTP compatible and safe solution >> that provides MUA configurations that expose aligned Sender header >> fields in lieu of aligned From header fields. > > I think implementing this suggestion would a disservice to the users > at both ends. The requisitioning author (a business) wants *her* > address, not the 3rd party's (Intuit's) address visible. The > recipient *also* wants to see and has a trust relationship with the > requisitioning author, not with Intuit. This is not about MUAs > AFAICS, it's about how an Author Domain can tell a recipient MTA > (DMARC verifier) that a particular sending MTA may use the Author > Domain in From. Dear Stephen, Sorry for not being clear. In the example given, this assumes a third-party service might be for a small outfit operating on a thin budget using an accounting firm to send messages on their behalf. Messages being sent may include a small outfit's email address assigned by their Internet provider in the From header field as permitted by RFC5322. Only by including known entities in the From header field will intended recipients be able to recognize their relationship with the author (the defined role of the From header field). To permit third-party services, it is also absolutely essential to recognize the role of Sender header fields as a means to properly retain the role of the From header field. To be compliant with SMTP, policy must permit acceptance of Sender header fields representing the agent responsible for message transmission per RFC5322. This scenario could apply in any number of situations, nor should this be dismissed with a suggestion there are From header field re-write work-arounds to deal with DMaRCs' disruption which defeats the explicit role of the From header field and ignores the role of the Sender header field. Whether for mailing-lists such as this, financial services by an accounting firm, or the forwarding of messages from alumni accounts, the whole email address in the From header field plays a vital role and MUST NOT be considered to represent the property or the brand of the provider. The email address represents the inbox of the individual author. Only by allowing policy alignment acceptance based on the Sender header field, especially for domains providing general email service, the From header field containing the recognized entity would be displayed as it is now, in addition to an aligned Sender header field indicating that the message past through the third-party service. Mailing-lists often ensure their role is clearly indicated by adding tags in the Subject header field, but this can also be done using Outlook's "on behalf of" which combines the Sender header field together with that of the From, or simply displaying the Sender header field which is often an option available in the MUA. What was meant by "in lieu of aligned From header fields" was to permit acceptance based on the Sender header field as well. The TPA-Label scheme can also offer the mechanism you described. > This needs no help from the MUA (unless it's a DMARC verifier itself), > and need not be visible at all to the user. Disagree. Asserting policy that attempts to minimize successful spoofing of transactional domains is being misapplied when solely based on the From header field against domains that offer general purpose email services as defined by RFC5321/RFC5322 et al. Displaying the Sender header field as an additional field, or in the form of "on behalf of", would make successful phishing far less likely. TPA-Label can be used to ensure good actors are accepted while being less dependent on caution asserted by recipients. This is a service we would be willing to offer a large provider to demonstrate the practicality and the scalability of this approach. The goal is to retain the agility and utility that had been offered by email. As it currently stands, the only quick fix for the abusive misuse of DMaRC policy has been to change "reject" to "quarantine". Another remedy might be to systematically include the Sender header field in alignment assessments where the domains then need to ensure the proper display of the message source. Regards, Douglas Otis
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
