About emails impersonating Path Network
mike at mtcc.com
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.
More information about the NANOG