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 <d...@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.