Re: DMARC methods in mailman --- [LEDE-DEV] DMARC related mass bounces / disabled subscriptions (fwd) Jo-Philipp Wich: [LEDE-DEV] DMARC related mass bounces / disabled subscriptions

[Viktor Dukhovni <[e-mail]>]

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.

-- 
	Viktor.