> On Fri, Dec 16, 2016 at 03:27:04PM -0500, Theodore Ts'o wrote: > > The real problem with all of these schemes is as they make life easier > > for the user, it also makes life user for the phishers. So for > > example, if we start adding a mail header field "this is *really* the > > sender", or there is a standard way to parse it out of the comments of > > the from field, then it will also provide a better user experience and > > a better user interface to display that as the summary line of the > > e-mail, and in the mail headers that are displayed for the user. > > > > And the moment you do that, the phishers will use that to exploit > > stupid uesrs, and then there will be a DMARCv2 that will break that > > field, and perhaps, break mailing lists again. :-( > The real problem that DMARC "solves" is reducing the work-load of > the abuse desks of the domains publishing DMARC records. DMARC > has nothing to do with protecting end-users from phishing. > When it is more difficult to forge an email from a Yahoo user, it > is more convenient for the phisher to fake an address from some > other domain, and then Yahoo deals with fewer complaints. > The RFC2822.From field is not a particularly important element in > determining whether a phishing email is effective. What matters > is sufficiently compelling message content. > There too little correlation between the purported (in message > content) sending organization and the RFC2822.From in a large > fraction of legitimate email, for users to carefully check or rely > on that field. And the various fixes, hacks, workarounds, and so on to the problems caused by DMARC are ony weakening that correlation further. Ned