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

[[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.

And the various fixes, hacks, workarounds, and so on to the problems caused by
DMARC are ony weakening that correlation further.

				Ned