Multipurpose Internet Mail Extensions

De Wikipedia
Saltar a navegación Saltar a la gueta

Multipurpose Internet Mail Extensions o ACORIQUE (n'español "estensiones multipropósito de corréu d'internet") son una serie de convenciones o especificaciones empobinaes al intercambiu al traviés de Internet de too tipu d'archivos (testu, audiu, vídeu, etc.) de forma tresparente pal usuariu. Una parte importante del ACORIQUE ta dedicada a ameyorar les posibilidaes de tresferencia de testu en distintos idiomes y alfabetos. En sentíu xeneral les estensiones d'ACORIQUE van empuestes a soportar:

  • Testu en conxuntos de calteres distintos de US-ASCII;
  • adxuntos que nun son de tipu testu;
  • cuerpos de mensaxes con múltiples partes (multi-part);
  • información d'encabezadures con conxuntos de calteres distintos de ASCII.

Prácticamente tolos mensaxes de corréu electrónicu escritos por persones en Internet y una proporción considerable d'estos mensaxes xeneraos automáticamente son tresmitíos en formatu ACORIQUE al traviés de SMTP. Los mensaxes de corréu electrónicu n'Internet tán tan cercanamente acomuñaos col SMTP y ACORIQUE que usualmente llámase-yos mensaxe SMTP/ACORIQUE.[1]

En 1991 la IETF (Grupu de Trabayu n'Inxeniería d'Internet, Internet Engineering Task Force n'inglés) empezó a desenvolver esta norma y dende 1994 toles estensiones ACORIQUE tán especificaes de forma detallada en diversos documentos oficiales disponibles n'Internet.

ACORIQUE ta especificáu en seis Request for Comments o RFC (n'español "solicitú de comentarios): RFC 2045, RFC 2046, RFC 2047, RFC 4288, RFC 4289 y RFC 2077.

Los tipos de conteníu definíos pol estándar ACORIQUE tienen gran importancia tamién fuera del contestu de los mensaxes electrónicos. Exemplu d'esto son dalgunos protocolo de rede tales como HTTP de la Web. HTTP rique que los datos sían tresmitíos nun contestu de mensaje tipo y-mail anque los datos pueden nun ser un y-mail puramente dichu.

Na actualidá nengún programa de corréu electrónicu o navegador d'Internet puede considerase completu si nun acepta ACORIQUE nes sos distintes facetes (testu y formatos d'archivu).

Introducción[editar | editar la fonte]

El protocolu básicu de tresmisión de mensaxes electrónicos d'Internet soporta namá calteres ASCII de 7 bit (vease tamién 8BITMIME). Esto llinda los mensaxes de corréu electrónicu, yá que inclúin namá calteres abondos pa escribir nun númberu amenorgáu de llinguaxes, principalmente Inglés. Otros llinguaxes basaos nel Alfabetu llatinu ye adicionalmente un componente fundamental en protocolos de comunicación como HTTP, el que rique que los datos sían tresmitíos como un y-mail anque los datos pueden nun ser un y-mail puramente dichu. Los veceros de corréu y los Servidor de corréu servidores de corréu converten automáticamente dende y a formatu ACORIQUE cuando unvien o reciben (SMTP/ACORIQUE) y-mails.

Nomenclatura de tipos[editar | editar la fonte]

ACORIQUE asigna un nome a cada tipu de datos. Los nomes siguen el siguiente formatu:

tipu/subtipo (tipu como subtipo son cadenes de calteres)

El tipu define la categoría xeneral de los datos y el subtipo define un tipu más específicu d'esos datos. El tipu puede contener los siguientes valores:

  • text: Indica que'l conteníu ye testu planu. Exemplos de subtipos: html, xml
  • multipart: Indica que tien múltiples partes de datos independientes. Exemplos de subtipos: form-data, digest
  • message: Pa encapsular un mensaxe esistente. Por casu cuando queremos responder a un mensaxe de corréu incorporando'l mensaxe orixe. Exemplos de subtipos: partial, rfc822
  • image: Indica que ye una imaxe. Ej de subtipos: png, gif
  • audiu: Indica que ye un audiu. Exemplos de subtipos: mp3, 32kadpcm
  • video: Indica que ye un video. Exemplos de subtipos: mpeg, avi
  • application: Indica que se trata de datos d'aplicación los cualos pueden ser binarios. Exemplos de subtipos: json, pdf

ACORIQUE headers[editar | editar la fonte]

ACORIQUE-Version[editar | editar la fonte]

La presencia d'esta encabezadura indica que'l mensaxe utiliza'l formatu ACORIQUE. El so valor ye típicamente igual a "1.0" polo qu'esta encabezadura apaez como:

ACORIQUE-Version: 1.0

Tien De señalase que los implementadores intentaron camudar el númberu de versión nel pasáu y el cambéu tuvo resultancies imprevistes. Nuna xunta de IETF realizada en xunetu 2007 decidió caltenese el númberu de versión en "1.0" anque se realizaron munches actualizaciones a la versión d'ACORIQUE.

Content-Type[editar | editar la fonte]

Esta encabezadura indica'l tipu de mediu que representa'l conteníu del mensaxe, consiste nun tipu: type y un subtipo: subtype, por casu:

Content-Type: text/plain

Al traviés del usu del tipu multiparte (multipart), ACORIQUE da la posibilidá de crear mensaxes que tengan partes y subpartes entamaes nuna estructura arbórea na que los nodos fueya pueden ser cualquier tipu de conteníu non multiparte y los nodos que nun son fueyes pueden ser de cualesquier de les variedaes de tipos multiparte. Esti mecanismu soporta:

  • mensaxes de testu planu usando text/plain (este ye'l valor implícitu pa la encabezadura "Content-type:")
  • testu más archivos axuntos (multipart/mixed con una parte text/plain y otres partes que nun son de testu, por casu: application/pdf pa documentos pdf, application/vnd.oasis.opendocument.text para OpenDocument text). Un mensaxe ACORIQUE qu'inclúi un archivu axuntu xeneralmente indica'l nome orixinal del archivu con una encabezadura "Content-disposition:" o por un atributu name de Content-Type, polo qu'el tipu o formatu del archivu indícase usando tantu la encabezadura ACORIQUE content-type y la extensión del archivu (usualmente dependiente del SO).
Content-Type: application/vnd.oasis.opendocument.text;
name="Carta.odt"
Content-Disposition: inline;
filename="Carta.odt"
  • reenviar col mensaxe orixinal axuntu (multipart/mixed con una parte text/plain y el mensaxe orixinal como una parte message/rfc822)
  • conteníu alternativo, un mensaxe que contien el testu tantu en testu planu como n'otru formatu, usualmente HTML (multipart/alternative col mesmu conteníu en forma de text/plain y text/html)
  • munches otres construcciones de mensaxe

Content-Transfer-Encoding[editar | editar la fonte]

En Xunu de 1992, ACORIQUE (RFC 1341 queda obsoleta pola nueva RFC 2045) define un conxuntu de métodos pa representar datos binarios usando testu ASCII. La encabezadura ACORIQUE content-transfer-encoding: indica'l métodu que foi usáu. La RFC y la llista de IANA definen los siguientes valores, que nun son sensibles a mayúscules nin minúscules:

  • Fayadizos pa usar con SMTP:
    • 7bit — soporta hasta 998 octetos per llinia de códigu; los calteres tán nel rangu ente 1..127 con CR y LF (códigos 13 y 10 respectivamente) que namá pueden apaecer como parte d'un fin de llinia CRLF. Este ye'l valor implícitu pa esta encabezadura.
    • Quoted printable — usáu pa codificar secuencies arbitraries de octetos de forma que satisfaiga les riegles de 7bit. Foi diseñáu pa ser eficiente y na mayoría de los casos legible pa un humanu cuando ye usáu con datos de testu que consisten primariamente en calteres del conxuntu US-ASCII y que tamién contengan porciones de bytes con valores que tán fora d'esi rangu.
    • base64 — usáu pa codificar secuencies arbitraries de octetos de forma que satisfaiga les riegles de 7bit. Tien una sobrecarga fixa al executar l'algoritmu y tien el propósitu de ser usáu con datos que nun sían de testu o testos que contengan pocos valores dientro del rangu de ASCII.
  • Fayadizu pa usar con servidores SMTP que soporten 8BITMIME estensiones SMTP:
    • 8bit — soporta hasta 998 octetos per llinia de códigu, los calteres tán nel rangu ente 1..256 con CR y LF (códigos 13 y 10 respectivamente) que namá pueden apaecer como parte d'un fin de llinia CRLF.
  • Afechos namá pa usar con servidores SMTP que soporten la estensión SMTP BINARYMIME (RFC 3030):
    • binary — cualquier secuencia de octetos.

Nun esiste una codificación definida explícitamente pa unviar datos binarios arbitrarios al traviés d'un tresporte SMTP coles estensiones 8BITMIME. Por tanto base64 o quoted-printable (coles sos ineficiencias acomuñaes) tienen que ser usaes entá. Estes restricciones nun s'apliquen a otros usos d'ACORIQUE como son Servicio Web con adxuntos ACORIQUE o MTOM

Encoded-Word[editar | editar la fonte]

Dende la RFC 2822, los nomes y valores de les encabezadures ACORIQUE de mensaxes son siempres calteres ASCII; los valores que contengan otru tipu de calteres tienen qu'usar la sintaxis de palabra codificada o encoded-word (RFC 2047) en llugar del testu lliteral. Esta sintaxis utiliza una cadena de calteres ASCII qu'indica'l conxuntu de calteres orixinal (el "charset") y el content-transfer-encoding usáu pa mapear los bytes del conxuntu orixinal a calteres ASCII.

La so forma xeneral ye:

=?charset?codificación?testu codificado?=
  • charset puede ser cualquier conxuntu de calteres rexistráu con IANA. Típicamente va coincidir col charset del cuerpu del mensaxe.
  • codificación puede ser: "Q" que denota Q-encoding que ye similar a la codificación quoted-printable, o "B" que denota la codificación base64.
  • testu codificado ye'l testu codificado con Q-encoding o base64.

Diferencies ente Q-encoding y quoted-printable[editar | editar la fonte]

Los códigos ASCII del signu d'entruga (?) y el signu d'igualdá (=) nun pueden ser representaos directamente cuidao que ellos son usaos como allindiadores del encoded-word. El códigu ASCII reserváu pal espaciu nun puede ser representáu directamente porque puede causar qu'intérpretes antiguos estremen, de forma ensin deseyar, el encoded-word. Pa faer la codificación más pequena y bono de lleer, el símbolu sorrayáu (_) utilizar en llugar del espaciu, creando l'efectu colateral qu'esti símbolu non pueda representase directamente. L'usu de encoded-word en ciertes partes de les encabezadures impon otres restricciones sobre cuálos calteres pueden o nun ser representaos directamente.

Por casu:

Subject: =?utf-8?Q?=C2=A1Hola,_se=C3=B1or!?=

ye interpretáu como:

Subject: ¡Hola, señor!

El formatu encoded-word nun s'utiliza pa los nomes de les encabezadures (por casu Subject). Estos nomes d'encabezadures son siempres n'Inglés. Cuando se llee'l mensaxe con un veceru de corréu n'otru idioma que nun sía Inglés, los nomes de les encabezadures son traducíos pol veceru.

Mensaxes multiparte[editar | editar la fonte]

Un mensaxe ACORIQUE multiparte contien una frontera na encabezadura "Content-type:"; esta frontera, que nun puede apaecer en nenguna de les partes, ye allugada ente caúna d'elles, y al entamu y a la fin del cuerpu del mensaxe, como s'amuesa de siguío:

ACORIQUE-version: 1.0
Content-type: multipart/mixed; boundary="frontera"

This is a multi-part message in ACORIQUE format.
--frontera Content-type:
text/plain

Esti ye'l cuerpu del mensaxe --frontera Content-type:

application/octet-stream
Content-transfer-encoding: base64

PGh0bWw+CiAgPGhlYWQ+CiAgPC9oZWFkPgogIDxib2R5PgogICAgPHA+RXN0ZSBlcyBlbCBjdWVy
cG8gZGVsIG1lbnNhamU8L3A+CiAgPC9ib2R5Pgo8L2h0bWw+Cic=\
--frontera--


Cada parte consiste de la so propia encabezadura de conteníu (cero o más campos d'encabezadures Content-) y un cuerpu. El conteníu multiparte pue tar añeráu. L'encabezáu content-transfer-encoding d'un tipu multiparte tien siempres que ser "7bit", "8bit" o "binary" pa evitar los entueyos impuestos cola presencia de múltiples niveles de decodificación. El bloque multiparte, como un tou, nun tien especificación avera del conxuntu de calteres (charset); los calteres non ASCII nes encabezadures de la parte son remanaos al traviés de Encoded-Word, y los cuerpos de les partes pueden tener conxuntos de calteres especificaos si aplicara pal so tipu de conteníu.

Notes:

  • Antes de la primer frontera hai una área que ye ignorada por veceros de corréu electrónicu que soporten ACORIQUE. Esta área ye xeneralmente usada pa poner un mensaxe pa usuarios de veceros vieyos que nun soporten ACORIQUE.
  • Nun ye hasta'l momentu d'unviar el mensaxe que'l veceru de corréu escueye una cadena de calteres pa usar na frontera ente les partes, esto dexa buscar una cadena de testu que nun coincida con nenguna porción del cuerpu de nenguna de les partes. Esto típicamente ye implementáu usando una cadena llarga xenerada aleatoriamente.

Subtipos de Multiparte[editar | editar la fonte]

L'estándar ACORIQUE define dellos subtipos pa mensaxes multiparte, estos especifiquen la naturaleza de la parte del mensaxe y la so relación con otres partes. El subtipo ye especificáu na encabezadura "Content-type" pa tol mensaxe. Por casu, un mensaxe ACORIQUE multiparte qu'usa'l subtipo digest va tener un "Content-Type": "multipart/digest".

La RFC primeramente define 4 subtipos: mixed, digest, alternate y parallel. Una aplicación que cumpla mínimamente l'estándar tien de soportar siquier mixed y digest; el restu de los subtipos son opcionales. Otres RFCs definen subtipos adicionales como: signed y form-data.

Lo que sigue ye una llista de los subtipos más comúnmente usaos:

Mixed[editar | editar la fonte]

Multipart/mixed ye usáu pa unviar mensaxes o archivos con distintos encabezaos "Content-Type" yá sía en llinia o como axuntos. Si unvien imaxes o otros archivos fácilmente legibles, la mayoría de los veceros de corréu electrónicu van amosar como parte del mensaxe (nun siendo que se especifique de manera distinta la encabezadura "Content-disposition"). D'otra manera van ser ufiertaos como axuntos. El content-type implícitu pa cada parte ye "text/plain".

Definíu en RFC 2046, Sección 5.1.3

Message[editar | editar la fonte]

Una parte message/rfc822 contien un mensaxe de corréu electrónicu, incluyendo cualesquier Y-mail#Escritura del mensaxe encabezáu. Rfc822 ye un nome erróneu, cuidao que el mensaxe puede ser un mensaxe ACORIQUE completu. Ye usáu tamién pa resumenes el reenviar mensaxes.

Definíu na RFC 2046.

Digest[editar | editar la fonte]

Multipart/digest ye una forma simple d'unviar múltiples mensaxes de testu. El content-type implícitu pa cada parte ye "message/rfc822".

Definíu en RFC 2046, Sección 5.1.5.

Alternative[editar | editar la fonte]

El subtipo multipart/alternative indica que cada parte ye una versión "alternativa" del mesmu conteníu (o similar), caúna en formatos distintos denotados pola so encabezadura "Content-Type". Los formatos son ordenaos atendiendo a cuan fieles son al orixinal, col menos fiel al entamu. Los sistemes pueden escoyer la "meyor" representación qu'ellos son capaces de procesar; polo xeneral esta va ser la postrera parte que'l sistema entiende, nun siendo qu'otros factores puedan afectar esti comportamientu.

Cuidao que ye pocu probable qu'un veceru quiera unviar una versión que ye pocu fiel a la versión en testu planu, esta estructura alluga la versión en testu planu (si esiste) primeru. Esto facilita la xera de lleer los mensaxes pa los usuarios de veceros que nun entienden mensaxes multipartes.

Lo qu'asocede más comúnmente ye usar multipart/alternative pa mensaxes con dos partes, una como testu planu (text/plain) y una HTML (text/html). La parte en testu planu aprove compatibilidá con veceros vieyos que nun son capaces d'entender otros formatos, ente que la parte HTML dexa usar formatu de testu y enllaces. Munchos veceros de corréu ufierten al usuariu la posibilidá de preferir testu planu sobre HTML; esto ye un exemplu de como factores locales pueden afectar cómo una aplicación escueye cuál ye la "meyor" parte del mensaxe p'amosar.

Anque se pretende que cada parte represente'l mesmu conteníu, esto nun ye riquíu. Dellos filtros antispam esaminen namá la parte text/plain d'un mensaxe porque ye más bono d'analizar que les partes text/html. Pero los spammers al notar esto, empezaron a crear mensaxes con una parte text/plain qu'aparenta ser inocua ya inclúin la propaganda na parte text/html. Los mantenedores de programes anti-spam modificaron los sos filtros, penalizando a los mensaxes con testos bien distintos nun mensaxe multipart/alternative.

Definíu en RFC 2046, Sección 5.1.4

Related[editar | editar la fonte]

El subtipo multipart/related ye usáu pa indicar que les partes del mensaxe nun tienen de ser consideraes individualmente sinón como amestaos d'un tou. El mensaxe consiste d'una parte raigañu (implícitamente la primera) que fai referencia a otres partes, les que de la mesma pueden faer referencia a otres partes. Les partes son comúnmente referenciaes pola encabezadura: "Content-DÍI". La sintaxis de la referencia nun ta especificada sinón que ta dictada pola codificación o'l protocolu usáu na parte que contien la referencia.

Un usu común d'esti subtipo ye pa unviar página web completes con imaxes nun únicu mensaxe. Partir raigañu contendría'l documentu HTML, qu'usaría etiquetes HTML pa imaxes, pa referise a les imaxes almacenaes en partes subsiguientes.

Definíu en RFC 2387

Report[editar | editar la fonte]

Multipart/report ye un tipu de mensaxe que contien datos formateados por que un servidor de corréu interpretar. Ta ente un text/plain (o dalgún otru tipu de conteníu fácilmente legible) y un message/delivery-status.

Definíu en RFC 3462

Signed[editar | editar la fonte]

El subtipo multipart/signed ye usáu p'axuntar una firma dixital al mensaxe. Esta tien dos partes, una parte cuerpu y una parte robla. La parte del cuerpu completa, incluyendo les encabezadures ACORIQUE, ye usada pa crear la parte de la firma. Esisten munchos tipos de firmes, como application/pgp-signature y application/x-pkcs7-signature.

Definíu en RFC 1847, Sección 2.1

Encrypted[editar | editar la fonte]

Un mensaxe multipart/encrypted tien dos partes. La primera contien información de control que ye necesaria pa descifrar la segunda parte, de tipu: application/octet-stream.

Definíu en RFC 1847, Sección 2.2

Form Data[editar | editar la fonte]

Como'l so nome indicar, multipart/form-data ye usada pa espresar valores unviaos al traviés d'un formulariu. Originalmente definíu como parte de HTML 4.0, ye mayormente utilizáu pa unviar archivo vía HTTP.

Definíu en RFC 2388

Mixed-Replace (Esperimental)[editar | editar la fonte]

El tipu de conteníu multipart/x-mixed-replace foi desenvueltu como parte d'una teunoloxía pa emular server push y streaming sobre HTTP.

Toles partes d'un mensaxe mixed-replace tienen el mesmu significáu semánticu. Sicasí, cada parte invalida - "reemplaza" - a la parte previa asina ye recibida dafechu. Los veceros tienen de procesar la parte individual al momentu de la so llegada y nun tienen d'esperar a que termine'l mensaxe completu.

Desenvueltu originalmente por Netscape, entá ye soportáu por Mozilla, Firefox, Safari (pero non en Safari pa iPhone) y Opera, pero tradicionalmente ignorada por Microsoft.

Ver tamién[editar | editar la fonte]

Referencies[editar | editar la fonte]

RFC 1847 
Multiparte Seguro para ACORIQUE: Multipart/Signed y Multipart/Encrypted
RFC 2045 
ACORIQUE Parte Unu: Formatu y Cuerpu de Mensaxes d'Internet.
RFC 2046 
ACORIQUE Parte Dos: Tipos de Medios. N. Freed, Nathaniel Borenstein. Payares 1996.
RFC 2047 
ACORIQUE Parte Trés: Estensiones pa Encabezadures de Mensaxe pa testu non ASCII. Keith Moore. November 1996.
RFC 4288 
ACORIQUE Parte Cuatro: Especificación de Tipos de Medios y Procedimientos de Rexistru de los mesmos.
RFC 4289 
ACORIQUE Parte Cuatro: Procedimientos de Rexistru. N. Freed, J. Klensin. December 2005.
RFC 2049 
ACORIQUE Parte Cinco: Criteriu de Conformidá y Exemplos. N. Freed, N. Borenstein. November 1996.
RFC 2231 
Valores de Parámetros ACORIQUE y Estensiones Encoded Word : Conxuntos de Calteres, Llinguaxes, y Continuaciones. N. Freed, K. Moore. November 1997.
RFC 2387 
El Content-type ACORIQUE Multipart/Related
RFC 1521 
Mecanismos pa Especificar y Describir el Formatu de los Cuerpos de los Mensaxes d'Internet.

Enllaces esternos[editar | editar la fonte]



Multipurpose Internet Mail Extensions