About emails impersonating Path Network

Tue Feb 7 19:18:55 UTC 2023

On 2/7/23 6:09 AM, Rich Kulawiec wrote:
> On Mon, Feb 06, 2023 at 12:41:43PM -0800, Michael Thomas wrote:
>> This seems like a perfect object lesson on why you should use DKIM and SPF
>> and make sure the sending domain can set up a p=reject policy for DMARC.
> But it's not.  DKIM and SPF are mostly useless against competently executed
> email forgery -- and can even be exploited to make it worse.  Thanks to
> a combination of increasingly bad user interfaces, user ignorance,
> TLD proliferation, and the ill-advised conflation of identification with
> authenticity, it's not currently possible to stop email forgery in any
> meaningful sense of the word "stop".

There has been a real failing on the UI side, but that not the fault of 
the authentication protocols. Thunderbird which is what I use is 
completely useless and silent on authentication. For others who 
implement some UI indications, some of them aren't very obvious and 
often tentative. There is a Usenix paper which researched email auth and 
part of it was on user visible feedback. The long and short is that it 
was useful, but not a silver bullet. A large part of the problem from my 
read of it is that it wasn't ubiquitous and standardized ala the Lock 
icon on browsers. It's easy to make fun of that, but it is clearly 
better than nothing. MUA vendors are always at liberty to bring their 
requirements for extensions for protocols or even new protocols if it 
would help the user experience by guiding how MUA's make the UI 
decisions on the advice of senders. It's pretty clear that they find 
this niche at best. That is a pity because some uniformity could make 
this a positive feedback loop and up the utility greatly.

FWIW, lookalike domains can and do happen with http too. Nothing unique 
about that to email.

Mike