E-mails de origem (não críticos) de um host “menos confiável”

Question

Antecedentes

Temos um webapp sendo executado em webapp.example.com que (entre outras coisas) envia mensagens por e-mail de tempos em tempos. Essas mensagens não são críticas: embora nós gostaríamos de fazer um ótimo esforço para distribuí-las, o conhecimento de que a entrega da mensagem falhou não é de interesse.

Com isso em mente, ontem eu perguntei O que fazer se alguém não quiser receber e-mails devolvidos? —recuperativamente parece que a resposta é descartar tais rejeições após primeiro recebê-las (em vez de recusá-las, por exemplo, na camada SMTP ou inferior; ou transmitir as mensagens originais com um caminho de retorno nulo).

As opções

Suponha que as mensagens geradas pelo webapp tenham atualmente um caminho de retorno de [email protected] e, no DNS, o domínio example.com. esteja totalmente definido pelos seguintes registros:

@        SOA    ns.example.net. hostmaster 1 86400 7200 604800 300
         NS     ns.example.net.
         NS     ns.example.org.

         MX 1   mx.example.net.
         TXT    "v=spf1 a:192.0.2.0/24 -all"

webapp   A      198.51.100.1
         TXT    "v=spf1 a -all"

Nosso problema é que, para receber mensagens devolvidas (embora puramente para que possam ser descartadas ), pensamos que:

1. webapp.example.com deve executar um servidor SMTP que aceite as mensagens devolvidas;

2. alguma outra máquina deve executar um servidor SMTP que aceite as mensagens devolvidas, e um registro MX deve ser adicionado ao webapp.example.com. para que eles sejam entregues lá; ou

3. o caminho de retorno deve ser alterado, por ex. para [email protected] - nesse caso, não apenas os trocadores de mensagens do domínio devem aceitar as mensagens devolvidas, mas também:

   (a) a política do remetente para o domínio resultante, por exemplo example.com. , deve ser atualizado para incluir a:webapp.example.com ; ou

   (b) o webapp deve retransmitir todas as mensagens enviadas por meio de hosts aprovados pela política do remetente desse domínio, por exemplo, 192.0.2.0/24 .

Os problemas

A opção nº 1 é indesejável porque não queremos especialmente a exposição adicional de segurança da execução de um serviço público adicional na máquina que hospeda a aplicação web (pelo menos uma que realiza tão pouco).

A opção nº 2 é indesejável porque nosso único serviço de e-mail voltado ao público é fornecido por terceiros e a criação de novos domínios de destinatários está fora do escopo do nosso contrato de serviço existente.

A opção nº 3 (a) é indesejável porque não queremos conceder a permissão webapp.example.com para originar mensagens de outros remetentes em example.com .

A opção nº 3 (b) é indesejável porque implicaria a manutenção de uma conexão VPN do (com contato público) webapp.example.com para nossa rede segura somente interna.

Então, o que devemos fazer?

Talvez a opção 2 seja a melhor solução em muitos casos. No entanto, à luz dos motivos expostos acima, para nós, a opção nº 1 parece a menos ruim - e ainda assim parece um tremendo exagero. Existe uma maneira melhor?

    

Answer 1

Ao ler o tópico da sua pergunta anterior, percebo que você está usando o exim. Minha sugestão, então, seria configurá-lo como um MTA "somente envio". Eu pessoalmente usei este guia para configurar rapidamente servidores de e-mail somente de envio em redes públicas. Basicamente, o que ele faz é recusar conexões externas à porta SMTP.

Eu sei que não é a maneira mais "padrão" de resolver o problema, mas é muito prático.

A desvantagem é que alguns provedores de e-mail podem não gostar que o servidor de origem não possa ser contatado, e se recusaram a aceitar e-mails dele por completo. Na minha experiência, eu nunca vi tal coisa acontecer, mas eu acho que depende da quantidade de mensagens 'não-críticas' que você está enviando, e com que frequência essas mensagens são devolvidas.