Multipurpose Internet Mail Extensions (MIME) ouextensões multifuncionais O correio da Interneté umpadrão da Internetque estende oformatodedadosdee-mailspara suportar texto emcodificação de caracteresdiferentedeASCII, conteúdo não textual, conteúdo múltiplo e informações de cabeçalho em codificações diferentes deASCII. Como os e-mails são normalmente enviados porSMTPno formato MIME, esses e-mails costumam ser chamados dee-mailsSMTP / MIME.
Originalmente, o SMTP foi projetado para transferir apenas arquivos de texto (codificados em ASCII ). Com o surgimento da multimídia e o uso crescente de aplicativos de escritório, surgiu a necessidade de troca, além dos arquivos de texto, de arquivos binários (formato de aplicativos de escritório, imagens, sons, arquivos compactados).
Os tipos de conteúdo definidos pelo padrão MIME podem ser usados para outros fins que não o envio de emails, em protocolos de comunicação como HTTP para a World Wide Web .
O MIME é inicialmente especificado em cinco RFCs : RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049. RFC 2045 é complementado pelo RFC 2077. RFC 2048 , agora obsoleto, foi substituído pelo RFC 6838 e RFC 4289.
O protocolo básico de transmissão de e-mail, SMTP, suporta apenas caracteres ASCII (que têm 7 bits ). Isso limita os e-mails a mensagens que incluem apenas esses caracteres, o que é um pequeno número de idiomas como o inglês . Outros idiomas baseados no alfabeto latino , incluindo diacríticos, não são suportados pelo ASCII, portanto, essas mensagens não podem ser representadas adequadamente em e-mails básicos.
MIME define mecanismos para enviar outros tipos de informações, como texto usando codificações de caracteres diferentes de ASCII (e, portanto, possivelmente em um idioma diferente do inglês), ou dados binários (incluindo arquivos contendo imagens , sons , filmes ou programas de computador ).
MIME também é um componente fundamental de protocolos de comunicação como HTTP , que requerem o envio de dados no mesmo contexto do envio de emails , Mesmo que esses dados não sejam emails. A integração ou extração de dados em formato MIME geralmente é feita automaticamente pelo cliente de e-mail ou pelo servidor de e - mail quando o e-mail é enviado ou recebido.
O formato básico do e-mail é definido no RFC 2822, que é uma atualização do RFC 822. Esses padrões especificam o formato dos cabeçalhos e do corpo dos e-mails contendo texto, bem como cabeçalhos gerais como " To: ", " Subject: ", " From: " Ou " Date: ". MIME define um conjunto de cabeçalhos adicionais para o tipo de conteúdo da mensagem (" Content‑Type: ") e sua codificação de transferência (" Content-Transfer-Encoding: "). A codificação de transferência é a maneira de traduzir o conteúdo da mensagem para ASCII. Graças a esta tradução, o conteúdo inicial pode conter dados arbitrários de 8 bits (texto em UTF-8 , arquivo binário, etc.). O MIME também define um mecanismo para usar essa funcionalidade nos cabeçalhos das mensagens; isso permite, por exemplo, acentos no assunto de um e-mail ou no nome de um destinatário.
MIME é extensível. Sua definição inclui um método para registrar novos tipos de conteúdo ou outros valores de atributo.
Um dos outros objetivos explícitos da definição de MIME é não ter que alterar servidores de correio pré-existentes e permitir que o e-mail básico funcione adequadamente com clientes pré-existentes. Este objetivo é alcançado pelo fato de que os atributos das mensagens MIME são opcionais e que o comportamento padrão é a criação de uma mensagem de texto sem MIME que possa ser interpretada corretamente por um cliente.
A presença desse cabeçalho indica que o conteúdo da mensagem está formatado em MIME. O valor normalmente é "1,0", então o cabeçalho aparece como:
MIME-Version: 1.0Este cabeçalho indica o tipo de mídia da Internet do conteúdo da mensagem, consistindo em um tipo e um subtipo , por exemplo:
Content-Type: text/plainO MIME permite que as mensagens tenham várias partes organizadas em uma estrutura de árvore , usando um tipo " multipart " para nós internos.
Este mecanismo suporta em particular:
A especificação MIME ( RFC 2045 ) define um conjunto de métodos de transferência ou codificações (lembrados nesta lista da IANA ) para representar dados arbitrários como texto ASCII. O cabeçalho MIME " Content-Transfer-Encoding " indica o método usado. Pode ter um dos valores (não suscetível a quebra ) abaixo:
Nenhuma codificação é especialmente especificada para o envio de dados binários arbitrários por transportes SMTP com a extensão 8BITMIME. Os métodos Base64 ou Quoted-Printable (com suas respectivas ineficiências) devem ser usados. Essas restrições não se aplicam a outros usos de MIME, como serviços da Web com MIME ou anexo MTOM .
Os dados de texto (tipo " text ") são gravados em uma determinada codificação de caracteres , por exemplo latin-9 ou UTF-8 . Esta codificação pode ser especificada com o atributo charset= “ Content-Type: ” do cabeçalho “ ”. Isso pode assumir qualquer valor definido pela IANA . Por exemplo :
Content-Type: text/plain; charset=utf-8Esta codificação não deve ser confundida com a codificação de transferência , especificada pelo cabeçalho " Content-Transfer-Encoding: ". No caso de conteúdo textual, as duas codificações são aplicadas sucessivamente. Por exemplo :
Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ceci est un message encod=C3=A9 en UTF-8, puis transform=C3=A9 en ASCII par la m=C3=A9thode "Quoted-Printable".Neste exemplo, a letra "é" é codificada em UTF-8 por dois bytes de valores hexadecimais C3 e A9, que por sua vez são codificados em Quoted-Printable pela sequência " =C3=A9 ".
Desde a RFC 2822 , os nomes dos cabeçalhos das mensagens e seus valores são sempre em caracteres ASCII. Os valores que contêm dados não ASCII devem usar a chamada sintaxe de " palavra codificada " do MIME ( RFC 2047 ) no lugar dos valores de texto padrão. Essa sintaxe usa cadeias de caracteres ASCII para especificar a codificação original do texto (equivalente ao atributo charset=header Content-Type:) e a codificação de transferência (equivalente ao cabeçalho Content-Transfer-Encoding:).
A sintaxe é:
=?encodage?méthode?texte?=Os códigos ASCII para o ponto de interrogação ( ?) e o sinal de igual ( =) não devem ser representados diretamente, pois são usados para delimitar palavras codificadas. O código ASCII para o caractere de espaço também não deve ser usado, pois pode causar erros em codificadores mais antigos, como separação indesejada de palavras. Para tornar a codificação mais leve e fácil de ler, o caractere de sublinhado (" _ ") é usado para representar o espaço. Portanto, o caractere de sublinhado não pode mais ser representado diretamente. O uso de palavras codificadas em certas partes dos cabeçalhos impõe restrições aos caracteres a serem representados diretamente.
Por exemplo,
Subject: =?utf-8?Q?=C2=A1Hola,_se=C3=B1or!?=é interpretado como:
Assunto: ¡Hola, señor!O formato de palavra codificada não é usado para nomes de cabeçalhos (por exemplo " Subject: "). Esses nomes de cabeçalho estão sempre em inglês na mensagem. Quando a mensagem é exibida em um cliente de e-mail que não fala inglês, os nomes dos cabeçalhos podem ser traduzidos pelo cliente.
Uma mensagem MIME multiparte especifica uma linha separadora no cabeçalho " Content-type: ", por meio do atributo " boundary= ". Essa separação, que não deve aparecer em nenhum outro lugar, é colocada entre as partes e no início e no final do corpo da mensagem da seguinte forma:
Content-type: multipart/mixed; boundary="''frontière''" MIME-version: 1.0 This is a multi-part message in MIME format. --''frontière'' Content-type: text/plain This is the body of the message. --''frontière'' Content-type: application/octet-stream Content-transfer-encoding: base64 PGh0bWw+CiAgPGhlYWQ+CiAgPC9oZWFkPgogIDxib2R5PgogICAgPHA+VGhpcyBpcyB0aGUg Ym9keSBvZiB0aGUgbWVzc2FnZS48L3A+CiAgPC9ib2R5Pgo8L2h0bWw+Cg== --''frontière''--Cada uma dessas partes consiste em seu próprio cabeçalho de conteúdo (zero, um ou mais campos de cabeçalho Content-*:) e um corpo. Várias partes podem ser incluídas em outras várias partes, cada uma com seu próprio limite. O campo Content-Transfer-Encoding:de um tipo multiparte deve ser " 7bit ", " 8bit " ou " binary " para evitar problemas com a decodificação de diferentes camadas de multiparte. O bloco multipartes não tem conjunto de caracteres, os caracteres não ASCII nos cabeçalhos são processados pelo sistema de palavras codificadas e os corpos podem ter um conjunto de caracteres especificado apropriado para seu conteúdo.
Notas:
O padrão MIME define vários subtipos de mensagens multipartes para especificar a natureza das diferentes partes da mensagem e seus relacionamentos com outras partes. O subtipo é especificado pelo cabeçalho " Content-type: " da mensagem envolvente. Por exemplo, uma mensagem MIME multiparte usando o subtipo " digest " deve ter seu cabeçalho " Content-Type: " para " multipart/digest ". O RFC Inicialmente define quatro subtipos: " mixed ", " alternate ", " digest " e " parallel ". Um aplicativo deve suportar pelo menos os subtipos “ mixed ” e “ digest ”, os outros são opcionais. Subtipos adicionais como " signed " ou " form-data " foram definidos em outros RFCs .
Os seguintes subtipos são usados principalmente:
mixedO tipo " multipart/mixed " (definido em RFC2046, Seção 5.1.3 ) é usado para enviar arquivos com cabeçalhos Content-type: " " diferentes (como anexos). Se os arquivos são facilmente legíveis ou são imagens, a maioria dos clientes de e-mail exibe esses arquivos diretamente no conteúdo da mensagem (a menos que um cabeçalho " Content-disposition: " especifique o contrário). Caso contrário, os arquivos são vistos como anexos. O tipo de conteúdo padrão para essas partes é " text/plain ".
O RFC também especifica que todos os subtipos de " multipart " não reconhecidos por uma implementação devem ser tratados da mesma forma que " multipart/mixed ".
digestO tipo " multipart/digest " (definido em RFC2046, Seção 5.1.5 ) é a maneira simples de enviar várias mensagens de texto. O tipo de conteúdo padrão é " message/rfc822 ".
alternativeO tipo " multipart/alternative " (definido em RFC2046, Seção 5.1.4 ) indica que cada parte é uma versão alternativa do mesmo conteúdo em um formato diferente. Os formatos são ordenados em ordem crescente de fidelidade ao conteúdo original. O destinatário pode assim escolher a melhor representação que é capaz de processar, em geral, a última da lista.
Como um cliente geralmente não deseja enviar conteúdo menos significativo do que texto simples, ele é enviado primeiro, o que simplifica o processamento para clientes que não entendem o tipo " multipart ", pois esta é a parte visível do texto .
O principal uso do tipo " multipart/alternative " é enviar emails em formato HTML com seu equivalente em formato de texto para manter a legibilidade da mensagem para um cliente de email que não pode exibir HTML (cliente de texto).
Embora cada parte da postagem deva representar o mesmo conteúdo, não há garantia. Por exemplo, é mais fácil para um filtro de spam verificar a parte do texto simples de uma mensagem em vez da parte HTML; enquanto o editor de spam, em vez disso, construirá uma mensagem HTML com seu conteúdo publicitário e uma mensagem de texto simples inócua ou não relacionada à sua publicidade.
O tipo " multipart/related " (definido em RFC2387 ) é usado para especificar que as diferentes partes não devem ser tratadas individualmente, mas como um todo. A mensagem consiste em uma parte raiz (a primeira, por padrão) que faz referência a outras partes, que também podem fazer referência a outras partes. Partes das mensagens são frequentemente referenciadas por seu identificador de conteúdo (cabeçalho " Content-ID: "). A sintaxe das referências não é especificada, é deixada ao critério do protocolo utilizado.
Um dos usos comuns desse subtipo é enviar uma página da web com suas imagens em uma única mensagem. A parte raiz contém o documento HTML e as imagens são armazenadas nas seguintes partes.
reportO tipo " multipart/report " (definido em RFC3462 ) representa uma mensagem que contém dados formatados para serem lidos por um servidor de e-mail. Ele contém uma parte do tipo " text/plain " (ou outro conteúdo facilmente legível) e outra do tipo " message/delivery-status " que contém os dados formatados para o servidor de e-mail.
signedO tipo " multipart/signed " (definido em RFC1847, Seção 2.1 ) é usado para anexar uma assinatura digital a uma mensagem. É composto por duas partes: o corpo da mensagem e a assinatura. Toda a parte do corpo da mensagem, incluindo os cabeçalhos MIME, é usada para gerar a assinatura. Diferentes tipos de assinaturas são possíveis, como " application/pgp-signature " ou " application/x-pkcs7-signature ".
encryptedO tipo " multipart/encrypted " (definido em RFC1847, Seção 2.2 ) é usado para enviar conteúdo criptografado . Sua primeira parte define as informações necessárias para decifrar sua segunda parte (do tipo " application/octet-stream ").
form-dataO tipo " multipart/form-data " (definido em RFC2388 ) é usado para enviar dados de um formulário. Definido originalmente como parte do HTML 4.0 , é mais comumente usado para enviar arquivos por HTTP .