Forgotten Powers of MIME

by J.D. Falk
Director of Product Strategy, Receiver Services

If you attended the MAAWG meeting near Washington, D.C. this week, you may have seen postcards from Return Path containing what I believe are fully RFC-compliant email message headers referring to this very blog.

I did have to fudge the Received: header a bit, because there’s no standard way to denote messages injected into the mailstream on a postcard. Maybe there should be. But Received: is somewhat loosely defined, so I think it’s close enough.

While creating the postcard, I stumbled across a very cool idea left over from the invention of MIME, updated a few years later…but never, so far as I could figure out, implemented.

Content-Type: message/external-body; access-type=URL;

A MIME part with a content-type of “message/external-body” is, quite simply, a reference to something stored elsewhere. MIME’s inventors imagined that it could be a way to include images and such, accessed originally from an FTP site, a local file, a mail server (though how this would work is unclear), or a few other methods. In 1996, RFC 2017 added the ability to reference a URL — which, in effect, lets you include absolutely anything.

An obvious use for this feature would be to pull up a web page containing information which may have been updated since the message was originally sent — shipping status, flight arrival times, et cetera. These things are often attempted today using JavaScript or other technologies embedded in an HTML message, but that usually doesn’t work due to security concerns.

An equally obvious use for this feature would be to deliver malware and other badness, bypassing spam filters that only look at the content of the original message itself. I doubt that’s the only reason this idea was never implemented, but it sure is a serious concern.

Still, I wonder if there’s a way this could be done right…maybe by adding a Certification layer to keep the bad guys out?

Prev Next

minute read

Popular stories