Internet and e-mail policy and practice
including Notes on Internet E-mail


2015
Months
Jun

Click the comments link on any story to see comments or add your own.


Subscribe to this blog


RSS feed


Home :: Email

16 Jun 2015

The cycle of e-mail security Email

Stepping back from the DMARC arguments, it occurs to me that there is a predictable cycle with every new e-mail security technology.

1. Invention and enthusiasm

Someone invents a new way to make e-mail more secure, call it SPF or DKIM or DMARC or (this month's mini-fiasco) PGP in DANE. Each scheme has a model of the way that mail works. For some subset of e-mail, the model works great, for other mail it works less great.

SPF works great for mail sent directly from the sender's server to the recipient, not for mail that is relayed or mail sent from a third party server (the usual example is newspaper send-an-article.) DKIM works great for mail sent or relayed from the sender's server, so-so for mail that is modified as it's relayed (mailing lists) or from third party servers. DMARC works great for much of the mail where SPF or DKIM works, not at all otherwise. In each case, the range of mail that each handles is a large fraction of all mail, but a large fraction is not the same as all.

2. Overselling the benefits and getting FUSSPy

The ball gets rolling, the enthusiasts see how great the scheme is, and how well it works for the mail that fits the model. Sometimes the enthusiasts are different from the inventors, and it is common for the enthusiasts not to understand the model very well. For example, DKIM is deliberately designed so that the domain in a DKIM signature need not match the From: or anything else, which provides a great deal of useful flexibility. But some enthusiasts insisted that "first party" signatures that matched the From:, or maybe the Sender:, were more legitimate than others.

The next step is to observe that if only all legitimate mail fit the model (either the real model or the enthusiasts' model) we could reject the rest and solve the spam problem, or in the case of DMARC, the phishing problem. Never mind that all mail doesn't fit any model, and no mechanical scheme will ever perfectly separate good mail from bad, the lure of a FUSSP is hard to resist.

3. Slandering mail that doesn't fit the model

Since mail that doesn't match the scheme's model is inconvenient, it must therefore also be bad. So the enthusiasts borrow derogatory terms to describe it, with "forged" being the most common. No, mailing lists do not forge mail from subscribers, and courtesy forwarders like computer.org do not forge the origin of the mail they resend.

When the enthusiasts start rejecting mail that doesn't fit the scheme's model, they lose a lot of perfectly good mail, but that of course is the fault of people sending forged mail.

Or they insist that people use clumsy workarounds like SRS which reinvented source routing (which SMTP mail ditched in the 1990s) to try and deal with limitations in SPF.

Or worse, they admit that the model has its limits, but the benefits of the scheme are so overwhelming that the collateral damage is a small cost to pay for progress and only a Luddite would object. Particularly since the cost is invariably paid by someone else.

4. A truce, if you're lucky

SPF and DKIM are pretty well understood now, and it's rare to see mail rejected due to an overstrict SPF policy. DKIM is well integrated into the mail world.

DMARC is still in the "small cost for progress" stage, but current work in the IETF DMARC working group suggests there may be hope yet.


  posted at: 14:08 :: permanent link to this entry :: 0 comments
Stable link is https://jl.ly/Email/cycle.html

Topics


My other sites

Who is this guy?

Airline ticket info

Taughannock Networks

Other blogs

CAUCE
It turns out you don’t need a license to hunt for spam.
201 days ago

A keen grasp of the obvious
Italian Apple Cake
759 days ago

Related sites

Coalition Against Unsolicited Commercial E-mail

Network Abuse Clearinghouse

My Mastodon feed



© 2005-2024 John R. Levine.
CAN SPAM address harvesting notice: the operator of this website will not give, sell, or otherwise transfer addresses maintained by this website to any other party for the purposes of initiating, or enabling others to initiate, electronic mail messages.