Douglas Otis writes: > 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.
The use case is well-understood. I wish you'd stop assuming people have no clue. > 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. Nobody has ever suggested anything else. In particular, DMARC does not deprecate the Sender field in any way. DMARC is based on the hypothesis that phishing is most dangerous when the user believes that the *author* of a message is a familiar entity. That author is the entity in the From field, not anywhere else. That "From is author" (who may have delegated content creation to a third party as in the use case above, but who remains responsible for that content) is the RFC specification, my personal practice, and strongly supported by years of experience on Mailman channels with users confused by Outlook's "on behalf of" presentation. These users often understand "on behalf of" to mean that Sender is the author, and believe that the author is no longer responsible for content. That phishing is most facilitated by spoofing the From field seems plausible to me, but as I see it your task is to convince Yahoo! and AOL, not me and not the IETF. Or perhaps you can sell third-party sender auth to banks and government agencies who want to allow their representatives to participate in mailing lists like this one with their "official" addresses, and maybe Yahoo! and AOL will go along. > 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. It does not. It represents whatever the terms of service for the inbox say. This is a problem of contract law, not of the email protocol. DMARC does not take a stand on terms of service AFAICS, but does warn that "p=reject" is inappropriate when those terms provide that the email address denotes a personal inbox. I agree with you that failure of DMARC to provide for cases where authentication of Sender would provide information useful to the recipient is a major issue. However, I don't see how DMARC deprecates such authentication in any way. The reason it hasn't been developed, I believe, is that the banks don't need it and AOL and Yahoo! are pretty sure it would entail large on-going costs if it existed so they would not use it, either. If you have a protocol that can provide authentication for third-party senders, go sell it to Yahoo! and AOL. > > 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. [...] Displaying the Sender header field as an > additional field, or in the form of "on behalf of", would make > successful phishing far less likely. Do you have evidence for that? My experience says that displaying the Sender field would probably confuse many users who clearly do not know the difference between "From" and "Sender", while I *know for a fact* that "on behalf of" engenders such confusion. I see no reason to suppose such confusion would reduce the effectiveness of phishing. > TPA-Label can be used to ensure good actors are accepted > while being less dependent on caution asserted by recipients. I'm sure it can. But nobody cares what I think, except a few of my friends. What matters is what "p=reject" abusers think. Go forth and sell to *them*! Note well: they are not participating in this debate on this list. I know what conclusion I draw from that. http://snoopyandthegang.weebly.com/page-14.html _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
