MIME permitió que el correo transportara cualquier cosa añadiendo una cabecera content-type, no un nuevo sistema de correo.

El correo de los primeros tiempos de internet era solo ASCII, así que el cuerpo de un mensaje no podía transportar una imagen o un archivo de una forma en que todos los clientes estuvieran de acuerdo. MIME, las Extensiones Multipropósito de Correo de Internet (Multipurpose Internet Mail Extensions), se ideó para cambiar eso.

MIME surgió del Andrew Messaging System de la Universidad Carnegie Mellon como un formato de datos multiplataforma, y fue especificado por primera vez por el cocreador Nathaniel Borenstein y otros como la RFC 1341 en junio de 1992; la versión actual es el conjunto RFC 2045/2046/2047 de 1996.

Su diseño fue deliberadamente pequeño: una cabecera Content-Type nombra qué es la parte, una Content-Transfer-Encoding convierte binario en ASCII, y un límite multipart permite que un cuerpo contenga muchas partes. El mensaje sigue viajando por SMTP como antes.

Como la extensión se basaba en cabeceras y era opcional, cada cliente podía añadir soporte según su propio calendario, y MIME se convirtió rápidamente en la forma estándar de enviar adjuntos y correo con texto enriquecido, y más tarde en la base de la propia idea de content-type de la web.

Añadir una cabecera que dice qué es el cuerpo

Una cabecera content-type indica al receptor qué es una parte, de modo que puede decodificarla según una regla

base64 permite que binario arbitrario pase por un transporte solo ASCII

Los límites multipart permiten que un mensaje contenga texto y adjuntos juntos

Como el cambio era a nivel de cabecera, la adopción no requería un cambio conjunto obligatorio

Para extender un sistema ampliamente desplegado, añadir una pequeña pieza opcional de estructura, no un nuevo sistema: una cabecera que dice qué es la carga útil permite que cada implementador la adopte por su cuenta.

MIME se convirtió en el contenedor universal de los adjuntos de correo y es la razón por la que la cabecera Content-Type tomó prestada su idea para describir recursos web. La especificación original era escasa en presentación, así que se añadió Content-Disposition en la RFC 2183; en la práctica, muchos clientes siguen eligiendo la parte que mostrar con su propia lógica en lugar de seguir la recomendación del estándar.