[ih] Meta: attachment policy (was Re: clever usc creation)

[Dave Crocker]

On 7/18/2026 12:51 PM, Jack Haverty via Internet-history wrote:
> From a historical perspective, there has been lots of work in the past 
> to create technologies that address such problems.  In the email 
> world, that includes things like digital signatures, S/MIME, DMARC, 
> and many others.

PEM, PGP, and S/MIME actually do 'sign and encrypt a message'. All of 
them suffer basic problems with key administration and usability 
design.  Especially in a world with minimal adoption. These appear to be 
basic barriers.

If there were strong market demand, for a truly viable form of 
/interoperable/ end user email authentication and encryption, I suspect 
these barriers would get much better attention.  Alas, there isn't.


DKIM has come the closest except that, really, it does not sign the 
message.  This, of course, is at odds with how folk talk about it, but 
that disparity highlights some of the problems of doing security at 
scale.  (Much like the common refrain that using https means that you 
are talking to a secure server...)

DKIM uses crypto to attach an identifier to the message, so that the 
message stream using that identifier can be evaluated with almost no 
noise.  Quite different from protecting content authentication or 
privacy.  First, DKIM uses a domain name, rather than user identifier, 
for identification.  Second, it doesn't (have to) sign the entire message.

So, DKIM was only designed as a transmission channel signal, between the 
posting of a message and its associated delivery. (This echoes the 
authentication-related use of server-to-server PEM that TIS played with.)

Alas, its design has a hole which allows a collaborating sending user 
and a receiving host operator to re-post to additional recipients, but 
with no change in the signature.  This was certainly beyond its design goal.

DKIM was never intended to survive re-posting, since mailing lists, and 
the like, modify the message enough to break the signature.  Simple, 
classic MTA relaying does not modify the message (except for adding some 
trace header fields) and so the DKIM signature survives any number of 
MTA hops.  Serendipitously, aliasing does re-posting but only changes 
the SMTP RCPT-TO, and so DKIM survives that too.


DMARC was carefully designed only for use from a bulk-sender to direct 
recipients.  It validates use of the From: field domain name.  Hence, it 
really is doing some actual message authentication.  But precious 
little.  In reality, it is extending the model of validating sending 
platforms, more than message authors.

DMARC does not survive re-posting, but then, it wasn't intended to.

The expanded use that John L. cites was done by fiat and does break 
mailing list delivery.  The various hacks done to From: fields works 
around this problem, but only by making the From: field a lot less 
useful that it was.  By way of example, Jack is probably getting two 
copies of this message.  They  will be handled by his email system as 
coming from two different authors...

DMARC, therefore, should serve as a cautionary tail to designers about 
their expectations for use of their output.


DKIM2 has been underway for several years.  At base, it takes the lesson 
of strict, hop by hop compliance and extends it considerably.  That is, 
it is an infrastructure play, far beyond anything attempted for email so 
far. It will require adoption by everything in the handling sequence, 
from original posting to final delivery.

"Hop by hop":  Over quite a few interactions, with different folk, over 
an extended time, I have found this has sometimes meant compliance by 
posting and and delivering sites, but not classic MTA relays.  At others 
times it has meant every site touching the message.  (I haven't checked 
where the current language about this lands.)



> With all the work that went in to developing such technologies, going 
> as far back as the 1970s, personally I don't understand why nothing 
> seems to have happened, to at least make email more trustworthy.  
>  Anyone know more? 

Basic email functionality is simple and spectacularly useful. For all of 
the impressive array of functional enhancements that would make sense 
for it, it seems that 'good enough for basic use' defeated any market 
motivation for 'a lot better than that'. There have been quite a few 
demonstrations of the market's disinterest in more feature-packed 
capabilities.

d/

-- 
Dave Crocker

dhc at dcrocker.net
bluesky: @dcrocker.bsky.social
mast: @dcrocker at mastodon.social
+1.408.329.0791

Volunteer, Silicon Valley Chapter
Northern California Coastal Region
Information & Planning Coordinator
American Red Cross
dave.crocker2 at redcross.org