ietf
[Top] [All Lists]

Re: [IETF] DMARC methods in mailman

2016-12-26 10:08:53
Just another thought along the same lines.  If one is trying to
design an MUA (or web browser) to reduce phishing risk, the
following two design decisions should be high on the list of
things to avoid doing:

(i) If a message arrives with a head field of 
    From: Santa Claus <satanic-being@evil.example>
display
    From: Santa Claus 
to the user, presumably on the grounds that actual mailboxes are
ugly and a bad user experience.

(ii) If, in the middle of an HTML page, a construction appears
like:
   <a href="http://evil.example/satanic-being";>
https://santa-claus.example.com/ </a>
display
   https://santa-claus.example.com/
to the user without any comment.

As long as those implementing popular MUAs and browsers are
doing both of those things, it is really hard to hear about the
problems DMARC is supposedly solving.

   john


--On Monday, December 26, 2016 9:49 AM -0500 Theodore Ts'o
<tytso(_at_)mit(_dot_)edu> wrote:

On Sun, Dec 25, 2016 at 01:05:59PM -0500, Viktor Dukhovni
wrote:

The need for email origin authentication to specify that
"Sender" preempts "From" has been well understood for a long
time before there there was DMARC. If there is to be a
non-broken replacement, it must correct this design error and
place the "burden" of dealing with that on any MUAs that fail
to display Sender (as e.g. from <sender> on behalf of
<author>).

But if MUA's do this, then it becomes trivial to phish
consumers, which was the original excuse for DMARC.  So if
MUA's do this, eventually Yahoo and the other big mail
providers will promulgate a non-standard "fix" that will
bounce message with Sender lines that aren't equal to the From
field.   And then what will you do?

Hint: stop using mail providers that obey non-standard mail
protocols, because they *will* break you eventually, and/or
randomly.

                                      - Ted