Re: The real spoofing issue

[Antony Stone <An...@spamassassin.open.source.it>]

On Sunday 16 October 2016 at 17:30:19, Dianne Skoll wrote:

> Oh, and one more thing...
> 
> ... every email reader I've ever used shows neither the From: address nor
> the envelope sender by default.  They all default to showing the full name
> on the From: line, which naturally is impossible to protect or verify.

Indeed.  This is bad (but understandable, since (a) companies like Microsoft 
and Apple try to hide "all this technical stuff" from poor bewildered users, 
and (b) the majority of users would not know what to make of it anyway, unless 
the discrepancy were pointed out to them in no uncertain terms).

The growth of email on mobile devices with limited screen pixels doesn't help, 
either, since this encourages developers of web-based or client-based email 
systems to reduce the amount of detail shown to the user.

> I would love for mail readers to display this in the sender column:
> 
>    Dianne Skoll <df...@roaringpenguin.com> [spammer.org]

Yes.  Users seem (I don't really know, I've not done a survey, but I hope?) to 
have understood the "green locked padlock" / "red unlocked padlock" symbols in 
their browser address lines these days, for good and bad SSL connections, so 
surely something similar should be possible with email addresses?

> However, the DMARC people said UI design was not in DMARC's scope.  Meh.

"Meh" indeed, however I wonder if either:

 - some significant mail client provider (Thunderbird?) could be persuaded to 
implement this as a feature, and see whether others catch on and copy it

 - it could be included in some project such as MailScanner, which has access 
to the entire email content, and can also modify anything it likes, 
specifically including the subject, to highlight suspicious senders of the sort 
you've outlined above ?

I know there would be false positives from such a system (neatly summarised in 
a couple of your earlier postings in this thread), however these could be 
dealt with in the "local configuration" aspect of running any mail server, 
where the "trusted=doubtful" flag could be converted to "trusted=yes" for 
specific cases.

> (And I'm not even convinced that would offer much protection... end-users
> are wonderful at ignoring red flags.)

Yes, well, that's a well-known and well-documented problem outside the scope 
of any RFC, technical solution, system admin, or psychologist :(


Antony.

-- 
Perfection in design is achieved not when there is nothing left to add, but 
rather when there is nothing left to take away.

 - Antoine de Saint-Exupery

                                                   Please reply to the list;
                                                         please *don't* CC me.