ietf
[Top] [All Lists]

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

2016-12-17 02:52:59
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

<Prev in Thread] Current Thread [Next in Thread>