Mensagem devolvida - Bounce message

Uma mensagem devolvida ou apenas "devolvida" é uma mensagem automática de um sistema de e - mail , informando ao remetente de uma mensagem anterior que a mensagem não foi entregue (ou ocorreu algum outro problema de entrega). Diz-se que a mensagem original "foi devolvida".

Esse feedback pode ser imediato (algumas das causas descritas aqui) ou, se o sistema de envio puder tentar novamente, pode chegar dias depois do término dessas tentativas.

Os termos mais formais para mensagem devolvida incluem "Relatório de não entrega" ou "Recibo de não entrega" (NDR), [Falha] "Notificação de status de entrega" (DSN) mensagem ou uma "Notificação de não entrega" (NDN).

Classificação de rejeições

Embora o SMTP seja uma tecnologia madura, contando com mais de trinta anos, a arquitetura está cada vez mais sobrecarregada pela carga normal e não solicitada. Os sistemas de e-mail foram aprimorados com sistemas de reputação vinculados ao remetente real do e-mail, com a ideia de servidores de e-mail do destinatário rejeitando o e-mail quando um remetente forjado é usado no protocolo. Portanto, foram criados dois tipos de devoluções de e-mail: devoluções fortes e devoluções suaves. Ambos afetam a reputação de IP do remetente porque os provedores de serviço de e-mail (ESPs) consideram a taxa de rejeição total como um fator de decisão ao direcionar o e-mail para a caixa de entrada de um usuário. Resumidamente, a taxa de rejeição total é calculada como a soma da taxa de rejeição forte e da taxa de rejeição suave.

Hard bounces

Os hard bounces são permanentes e têm pontuação mais alta em termos de danos ao IP do remetente. O hard bounces ocorre quando o servidor de e-mail do remetente determina que existe uma grande probabilidade de o destinatário não estar disponível e provavelmente permanecerá assim. Algumas das ocasiões em que ocorrem hard bounces são quando o destinatário do e-mail se encontra em uma das seguintes situações: identificador incorreto / domínio incorreto (como um erro de digitação no endereço de e-mail ou no domínio) ou seu servidor não aceita mais e-mails. Nesse caso, a remoção dos endereços de e-mail que voltaram é obrigatória.

Saltos suaves

Os saltos suaves são temporários. Uma mensagem devolvida que passa por uma devolução suave pode ser tentada para ser reenviada em outro momento. Os soft bounces acontecem quando o destinatário do e-mail tem uma caixa de entrada cheia e, portanto, nenhum espaço para armazenar outro e-mail, ou um limite no tamanho dos e-mails que pode receber. Situações adicionais em que um salto suave aparece é um bloqueio configurado no e-mail do destinatário para marcar um determinado remetente como um remetente de 'spam' ou para colocar um determinado remetente na lista negra. Além disso, uma suspensão temporária do e-mail do destinatário ou um erro temporário em seus servidores também podem causar um salto suave.

Erros de entrega

Podem ocorrer erros em vários locais na entrega de correspondência. Um remetente pode, às vezes, receber uma mensagem devolvida de seu próprio servidor de e-mail, informando que não foi capaz de enviar uma mensagem ou, alternativamente, de um servidor de e-mail do destinatário informando que, embora tenha aceitado a mensagem, não é capaz de entregá-la ao do utilizador. Quando um servidor aceita uma mensagem para entrega, também aceita a responsabilidade de entregar uma mensagem devolvida no caso de falha na entrega.

Salto devido à falta de espaço em disco

Quando um e-mail chega ao servidor de destino para um endereço (como mymail.example, ao enviar para alice@mymail.example ), pode ser que o daemon de correio não seja capaz de depositar a mensagem na caixa de correio do usuário especificado se o o disco rígido subjacente do servidor não tem espaço suficiente.

Salto devido a destino inacessível

Ao enviar um e-mail, o serviço a partir do qual o e-mail é enviado pode não conseguir chegar ao endereço de destino. Nesse caso, o remetente receberá uma mensagem devolvida de seu próprio servidor de e-mail. Causas comuns para os servidores de e-mail não conseguirem chegar a um destino:

  • Incapaz de resolver o endereço de destino. Por exemplo, se o nome de domínio não existir.
  • Incapaz de estabelecer uma conexão com o endereço de destino. Por exemplo, se o endereço IP não estiver atribuído a um servidor ou se o servidor estiver offline .

Rejeição de mensagem forjada

Os usuários podem receber mensagens devolvidas errôneas sobre mensagens que nunca realmente enviaram. Isso pode acontecer em particular no contexto de spam de e- mail ou vírus de e- mail , onde um spammer (remetente) pode forjar uma mensagem para outro usuário (destinatário pretendido do spam) e forçar que a mensagem apareça de outro usuário (um terceiro) . Se a mensagem não puder ser entregue ao destinatário pretendido, a mensagem devolvida será "devolvida" ao terceiro em vez do spammer. Isso é chamado de retroespalhamento .

Outras causas

Se o servidor de e-mail library.example soubesse que a mensagem não poderia ser entregue (por exemplo, se Jill não tivesse uma conta de usuário), ele não teria aceitado a mensagem em primeiro lugar e, portanto, não teria enviado a devolução. Em vez disso, ele teria rejeitado a mensagem com um código de erro SMTP. Isso deixaria o servidor de email de Jack (em store.example ) a obrigação de criar e entregar uma devolução.

Terminologia

Bounces são uma forma especial de resposta automática . As respostas automáticas (respostas automáticas) são e-mails enviados por um programa - ao contrário de um usuário humano - em resposta a um e-mail recebido e enviado para o endereço de devolução .

Exemplos de outras respostas automáticas são e- mails de férias , desafios de filtragem de spam de resposta a desafios , respostas de servidores de lista e relatórios de feedback . Essas outras respostas automáticas são discutidas na RFC 3834: as respostas automáticas devem ser enviadas ao Return-Pathindicado no e-mail recebido que acionou a resposta automática e essa resposta é normalmente enviada com um caminho de retorno vazio; caso contrário, os respondentes automáticos podem ser impedidos de enviar respostas automáticas de um lado para outro.

O Return-Pathé visível no correio entregue como campo de cabeçalho Return-Pathinserido pelo agente de entrega de correio SMTP ( MDA ) (que geralmente é combinado com um agente de transferência de correio , ou MTA ). O MDA simplesmente copia o caminho reverso do MAIL FROMcomando SMTP para o Return-Path. O MDA também remove Return-Pathcampos de cabeçalho falsos inseridos por outros MTAs; este campo de cabeçalho geralmente reflete o último caminho reverso visto no MAIL FROMcomando.

Hoje, esses caminhos são normalmente reduzidos a endereços de e-mail comuns , já que o antigo ' roteamento de origem ' do SMTP foi preterido em 1989; para obter algumas informações históricas, consulte Esquema de reescrita do remetente . Ainda existe uma forma especial de caminho: o caminho vazio MAIL FROM:<>, usado para muitas respostas automáticas e, especialmente, para todas as devoluções.

Em sentido estrito, as devoluções enviadas com um não vazio Return-Pathestão incorretas. A RFC 3834 oferece algumas heurísticas para identificar devoluções incorretas com base na parte local (lado esquerdo antes do "@") do endereço em um não vazio Return-Path, e ainda define um campo de cabeçalho de correio,, Auto-Submittedpara identificar respostas automáticas. Mas o cabeçalho da mensagem é uma parte dos dados de correio (comando SMTP DATA), e MTA normalmente não olhar para o e-mail. Eles lidam com o envelope , que inclui o MAIL FROMendereço (também conhecido como Return-Path, Envelope-FROMou "caminho reverso"), mas não, por exemplo, o RFC 2822- Fromno campo de cabeçalho do e-mail From. Esses detalhes são importantes para esquemas como o BATV .

As devoluções restantes com um vazio Return-Pathsão notificações de falha na entrega ( NDRs ) ou notificações de status de entrega (DSNs). Os DSNs podem ser solicitados explicitamente com uma extensão de serviço SMTP, no entanto, não são amplamente usados. Solicitações explícitas para detalhes de falha de entrega são muito mais comumente implementadas com caminho de retorno de envelope variável (VERP), enquanto solicitações explícitas para eles raramente são implementadas.

NDRs são uma função SMTP básica. Assim que um MTA aceita um e-mail para encaminhamento ou entrega, ele não pode excluí-lo ("descartá-lo") silenciosamente; ele tem que criar e enviar uma mensagem devolvida ao originador se o encaminhamento ou entrega falhar.

Saltando contra rejeitando

Excluindo os MDAs, todos os MTAs encaminham e-mails para outro MTA. Este próximo MTA está livre para rejeitar o e-mail com uma mensagem de erro SMTP como "usuário desconhecido" , "acima da cota" , etc. Nesse ponto, o MTA de envio deve devolver a mensagem , ou seja, informar seu remetente. Uma rejeição também pode surgir sem a rejeição de um MTA, ou como diz o RFC 5321:

"Se um servidor SMTP aceitou a tarefa de retransmitir o e-mail e depois descobre que o destino está incorreto ou que o e-mail não pode ser entregue por algum outro motivo, ele DEVE construir uma mensagem de notificação de" e-mail não entregue "e enviá-la ao remetente do correio não entregue (conforme indicado pelo caminho inverso). "

Esta regra é essencial para SMTP: como o nome diz, é um protocolo 'simples', ele não pode funcionar de forma confiável se o e-mail desaparecer silenciosamente em buracos negros, então as devoluções são necessárias para detectar e corrigir os problemas.

Deixando mensagens silenciosamente

Hoje, no entanto, pode ser comum receber principalmente emails de spam , que geralmente usam Return-Paths forjados . Então, muitas vezes é impossível para o MTA informar o originador, e enviar uma devolução para o falsificado Return-Pathacertaria um terceiro inocente. Além disso, há razões específicas pelas quais é preferível descartar silenciosamente uma mensagem em vez de rejeitá- la (muito menos devolvê- la):

  • Spam filtrado heuristicamente . Os filtros de spam não são perfeitos. Rejeitar spam com base na filtragem de conteúdo implica fornecer aos spammers um ambiente de teste onde eles podem tentar várias alternativas até encontrarem o conteúdo que passa pelo filtro.
  • Vírus e worms . Na maioria das vezes, eles são enviados automaticamente de uma máquina infectada. Como um bounce pode conter uma cópia do próprio worm, ele pode contribuir para sua difusão.

Citando novamente RFC 5321, seção 6.2:

"Conforme discutido na Seção 7.8 e Seção 7.9 abaixo, descartar correspondência sem notificação do remetente é permitido na prática. No entanto, é extremamente perigoso e viola uma longa tradição e as expectativas da comunidade de que a correspondência seja entregue ou devolvida. for mal utilizado, pode facilmente prejudicar a confiança na confiabilidade dos sistemas de correio da Internet. Portanto, o descarte silencioso de mensagens deve ser considerado apenas nos casos em que há muita confiança de que as mensagens são seriamente fraudulentas ou inapropriadas. "

Não validar o remetente é uma falha inerente ao SMTP atual, que não contém as rotas de origem obsoletas mencionadas anteriormente. Isso é abordado por várias propostas, mais diretamente pela BATV e pela SPF .

Causas de uma mensagem de rejeição

Existem muitos motivos pelos quais um e-mail pode ser devolvido. Um dos motivos é se o endereço do destinatário está digitado incorretamente ou simplesmente não existe no sistema de recebimento. Esta é uma condição desconhecida do usuário . Outros motivos incluem esgotamento de recursos - como um disco cheio - ou a rejeição da mensagem devido a filtros de spam . Além disso, existem MUAs que permitem aos usuários "devolver" uma mensagem sob demanda. Essas rejeições iniciadas pelo usuário são rejeições falsas; por definição, um salto real é automatizado e emitido por um MTA ou MDA.

As mensagens devolvidas no SMTP são enviadas com o endereço do remetente do envelope <>, conhecido como endereço do remetente nulo . Eles são freqüentemente enviados com um From:endereço de cabeçalho de MAILER-DAEMONno site do destinatário.

Normalmente, uma mensagem devolvida contém várias informações para ajudar o remetente original a entender o motivo pelo qual sua mensagem não foi entregue:

  • A data e hora em que a mensagem foi devolvida,
  • A identidade do servidor de e-mail que o devolveu,
  • O motivo pelo qual foi devolvido (por exemplo, usuário desconhecido ou caixa de correio cheia ),
  • Os cabeçalhos da mensagem devolvida e
  • Parte ou todo o conteúdo da mensagem devolvida.

RFC 3463 descreve os códigos usados ​​para indicar o motivo do salto. Os códigos comuns são 5.1.1 (Usuário desconhecido), 5.2.2 (Caixa de correio cheia) e 5.7.1 (Rejeitado pela política de segurança / filtro de correio).

Formato

Os MTAs envolvidos em uma rejeição são nomeados de acordo com o ponto de vista do Reporting MTA . Os nomes de MTA geralmente são do tipo dns .

O formato para o relatório de mensagens administrativas é definido pela RFC  6522 . Um DSN pode ser uma mensagem MIME multipart / report composta de três partes:

  1. uma explicação legível por humanos;
  2. uma mensagem / status de entrega analisável por máquina , uma lista de linhas "nome: tipo; valor" que indicam vários campos possíveis; e
  3. a mensagem original, ou uma parte dela, como uma entidade do tipo mensagem / rfc822 .

A segunda parte de um DSN também é bastante legível. É essencial entender qual MTA desempenhou qual papel. O Reporting-MTA é responsável pela composição e envio do DSN.

Quando um Remote-MTA rejeita uma mensagem durante uma transação SMTP, um campo Diagnostic-Code do tipo smtp pode ser usado para relatar esse valor. Observe que, ao lado do valor numérico de 3 dígitos, a resposta SMTP contém uma parte legível por humanos. A informação 

Remote-MTA: dns; smtp.store.example [192.0.2.3]
Diagnostic-Code: smtp; 550 No such user here
às vezes é relatado como, por exemplo,
while talking to smtp.store.example [192.0.2.3]
>>> RCPT TO:<nonexistinguser@store.example>
<<< 550 No such user here

Veja também

RFCs relacionados

  • RFC  5321 - Protocolo Simples de Transferência de Correio
  • RFC  3461 - Extensão de serviço de protocolo de transferência de correio simples (SMTP) para notificações de status de entrega (DSNs)
  • RFC  6522 - O tipo de mídia multiparte / relatório para o relatório de mensagens administrativas do sistema de correio
  • RFC  3463 - Códigos de status aprimorados para SMTP
  • RFC  3464 - Um formato de mensagem extensível para notificações de status de entrega
  • RFC  3834 - Recomendações para respostas automáticas ao correio eletrônico
  • RFC  5337 - Status de entrega internacionalizado e notificações de disposição

Referências

links externos