O que fazer se não quiser receber e-mails devolvidos?

Question

Antecedentes - os padrões

RFC 5321 §4.5.5 declara:

All other types of messages (i.e., any message which is not required by a Standards-Track RFC to have a null reverse-path) SHOULD be sent with a valid, non-null reverse-path.

Para evitar dúvidas, RFC 2119 §3 define " DEVER "como" podem existir razões válidas em circunstâncias particulares para ignorar um item em particular, mas todas as implicações devem ser entendidas e cuidadosamente ponderadas antes de escolher um curso diferente. "

Situação

As "circunstâncias particulares" em consideração são onde Alice não deseja que receba notificações de status de entrega (relacionadas aos e-mails que ela originou).

Ela tem algumas opções:

1. ignora / descarta tais notificações quando ela as recebe - claramente esse comportamento seria totalmente correto, mas é um incômodo (e um desperdício de recursos);

2. recusar-se a aceitar tais notificações em algum nível inferior - sem dúvida o caminho inverso não seria mais "válido" (infelizmente não definido no RFC) e, nesse caso, tal comportamento é contrário às recomendações da RFC; ou

3. originam o email com um caminho inverso nulo para que as notificações nunca sejam geradas em primeiro lugar - claramente contrário às recomendações do RFC.

Perguntas

Tenho certeza de que essas circunstâncias constituem uma "razão válida" para ignorar a recomendação citada pela RFC acima, mas quero ter certeza de que entendi as "implicações completas" das opções 2 e 3.

Em particular, noto que:

• Na opção 2, alguns agentes podem detectar que o caminho inverso não é válido

• Na opção 3, alguns agentes podem tratar e-mails com caminhos reversos nulos como casos especiais

De qualquer forma, os agentes podem, consequentemente, recusar-se a aceitar / retransmitir / entregar o e-mail ou podem usar essas informações para aumentar a probabilidade de ser sinalizado como spam. Quão comuns são tais medidas na prática?

Existem outras preocupações / implicações que eu deveria considerar?

    

Answer 1

Usar a opção 1 é sempre a melhor solução. Pense nisso como correio de papel; um endereço de retorno funcional é obrigatório. O e-mail está ficando cada vez mais restrito (DMARC, etc) devido a spamers que se aproveitam da política aberta. Não é tão difícil automatizar lidar com respostas que você não se importa. Mas provavelmente menos de 10% dos servidores de e-mail são tão restritivos que você pode se safar. Certifique-se também de evitar que seu servidor seja listado em um dnsbl.

As regras são negligentes na maioria dos lugares (eu posso enviar um e-mail que parece que é de você, o que invocaria uma espécie de DDOS se eu enviasse para todo mundo e criasse para saltar) Olhe para todas as restrições em Postfix se você quiser saber quais regras podem estar em vigor.

Você não pode ter as duas coisas; faça corretamente (# 1) ou renuncie a ser spammer marcado (pelo menos alguns). O Google usa [email protected] e isso nunca chegará a meu alcance porque o meu servidor de e-mail exige um verificado remetente. O Google é o melhor em anti-spam, se não puder ter as duas coisas, tenho certeza de que não podemos.

    

Answer 2

4 - lidar com o salto.

Geralmente, a melhor abordagem é fazer com que o salto vá para algum tipo de processo de tratamento de rejeição para que o endereço do destinatário persistentemente possa ser removido do banco de dados. Qual poderia ser um .forward para "alice", ou ajustar o remetente do envelope para ser um processo do manipulador.

Se "alice" se importa ou não com o email, o servidor do destinatário administradores ou filtros costumam fazer. Em muitos casos, os servidores de destinatários contam cada salto como pontos negativos de reputação. Faça o suficiente e você acaba suas listas negras e você não conseguirá passar nada.

Não consuma recursos de outras pessoas porque você é muito preguiçoso para lidar com isso sozinho.

    

Answer 3

Em geral, eu concordo que o # 1 é provavelmente a melhor solução, você pode descartar qualquer retorno no servidor. Instale um .forward que envie mensagens para / dev / null. É improvável que sua conta de largura de banda seja prejudicada.

Para a discussão mais ampla sobre se você deve se preocupar com mensagens não sendo entregues, eu realmente não conheço ninguém que processe seus próprios retornos em qualquer escala, mas serviços como SendGrid, MailGun, etc. são ótimos nisso, eles permitem que você envie via HTTP POST, eles gerenciam a reputação do espaço IP e informam sobre correspondências retornadas e reclamações.

Para o seu caso, isso pode não ser essencial, mas, em geral, tento evitar o gerenciamento da minha própria entrega de e-mails em produção nos dias de hoje. Tanto pode dar errado, e pode ser uma grande distração de outros aspectos da manutenção de uma grande pilha da web.