Motivos legítimos do SMTP "MAIL FROM:" não corresponderá ao cabeçalho "From:" no DATA


18

Existe alguma razão legítima para o campo SMTP "MAIL FROM:" não corresponder ao campo "From:" na seção DATA de uma mensagem, além das listas de discussão?

Em /programming/1750194/smtp-why-does-email-needs-envelope-and-what-does-the-envelope-mean :

“Mas, para continuar sua metáfora do correio tradicional, a maioria das cartas profissionais conterá os endereços do remetente e do destinatário impressos na própria carta. Esses endereços não são necessários para o carteiro, mas são uma cortesia para o destinatário. Portanto, é sensato que o email funcione da mesma maneira. ”

O problema com essa linha de lógica está aqui: "cortesia ao destinatário". Incluir o endereço "De:" em um email via SMTP não é uma cortesia; é necessário se o destinatário puder enviar uma resposta.

From: Como limitar o cabeçalho From para corresponder a MAIL FROM no postfix? :

"Mas se você realmente deseja garantir From: e MAIL FROM, deve aplicar header_checks para que Return-Path: corresponda a From:"

Quais são as implicações de fazer isso? As listas de discussão obviamente seriam um problema. Existem outros usos legítimos de informações diferentes do cabeçalho "MAIL FROM:" e "From:"?

Respostas:


22

Há muitos motivos pelos quais os endereços Cabeçalho e Envelope de podem não corresponder. A maioria diz respeito aos processos automatizados de envio de mensagens, em que os problemas de entrega precisam ser relatados para um endereço que não é representativo de quem enviou a mensagem, ou para quem foi enviada em nome ou para quem deve ser respondida. As listas de discussão, como você apontou, são um bom exemplo.

O principal motivo pelo qual uma mensagem enviada do cliente de email de um usuário pode ter diferentes endereços é o email encaminhado. O conteúdo do correio deve ser razoavelmente fiel ao original, mas, no caso de erros de entrega, eles devem ser relatados ao usuário que encaminhou o email, não ao remetente original.

Além do cabeçalho SMTP, existem vários cabeçalhos MIME que vários programas usam para tentar distinguir entre o remetente original e o remetente intermediário e / ou o endereço preferencial para relatar erros. , Erros para, etc, etc, cada um com semântica diferente. Alguns deles têm suporte a padrões, enquanto muitos outros não, mas podem estar em uso de qualquer maneira. A maneira como vários programas de email se comportam na prática varia consideravelmente.

Se uma maneira de endereçar mensagens é aconselhável é uma questão diferente de ser "legítima", como você pergunta. Se você está considerando a legitimidade aqui em termos de algo como política para lidar com possíveis spams, não, acho que você não conseguirá fazer uma distinção simples dessa maneira.

Pense na assinatura de email DKIM e na autenticação SPF de servidores de email para domínios de email. Se você estiver enviando muito correio, talvez seja importante conseguir autenticar seus emails dessa maneira, e isso pode ter implicações no endereçamento de emails Dos cabeçalhos, pois você só pode autenticar emails relacionados a domínios para os quais você tem autoridade .

-

Prorrogado a pedido:

Um cabeçalho MIME 'Reply-To' direciona um MUA (agente de usuário de email, geralmente o cliente de email de uma pessoa) para enviar respostas para um endereço diferente, em vez do endereço MIME 'De'. Isso não é usado por um MTA (Mail Transport Agent) para coisas como erros.

Normalmente, um MTA usaria o endereço 'MAIL From' do envelope SMTP para enviar erros. A TI pode ser substituída por um cabeçalho MIME 'Errors-To', que é uma instrução MTA. Nem todos os MTAs o respeitarão, portanto, é um mecanismo inferior para definir o endereço do envelope SMTP, mas há muitas circunstâncias em que pode ser possível definir cabeçalhos MIME em uma mensagem, mas não o endereço SMTP do envelope. Por exemplo, o software em execução em um ambiente de hospedagem compartilhada pode se encontrar nessa situação.

'Remetente' é muito mais ambíguo como uma instrução para os agentes de software, mas indica quem ou o que enviou o email onde isso é distinto do endereço De, que é mais parecido com quem o email foi enviado em nome de. Por exemplo, quando você preencher um formulário on-line, envie um e-mail para seu político, seria muito apropriado que o e-mail resultante usasse seu e-mail no cabeçalho De, mas tenha um endereço de Remetente relacionado à organização que configurou o formulário.

'Originally-From' é usado por alguns softwares MUA ao encaminhar e-mails, com o endereço do encaminhador sendo usado para o cabeçalho 'From'. Outros MUAs deixarão o endereço De sozinho e usarão um cabeçalho 'Reenviar-de'. Se os MUAs que recebem esses vários emails de cabeçalhos interpretam os cabeçalhos de maneira útil ou mesmo os exibem é bastante variável. Ao responder a um email que foi encaminhado a você, para quem a resposta deve ser enviada por padrão? Talvez seja melhor definir o cabeçalho "Responder para"?

O comportamento dos MUAs é variável, e mal definido, embora pareça estar melhorando ao longo do tempo. Por outro lado, a semântica do envelope é muito mais definida. Normalmente, existe uma posição forte de que os MTAs nunca devem se preocupar com os cabeçalhos MIME, mas como os MTAs são cada vez mais responsáveis ​​pelo conteúdo de mensagens (por exemplo, consulte SPF e os padrões emergentes do DMARC), há pressão para que a clareza dessa posição seja degradada. Mecanismos de longa data, como Erros, também conflitaram com a noção de MTAs que não examinavam o conteúdo do cabeçalho, o que é parte do motivo pelo qual esses mecanismos sempre foram aplicados de maneira inconsistente. Filosofias de autores de software variam.

Você pode achar útil consultar http://tools.ietf.org/html/rfc4021#section-2 , mas lembre-se de que as práticas reais da infinidade de softwares de correio disponíveis variam de maneiras que não são necessariamente abençoadas pelos padrões.

Não há problema em tentar criar uma filosofia clara de como você acha que o correio deve ser usado, mas não espere que todos os outros façam as coisas como você acha que deveriam.


Ainda tenho tempo para conceder essa recompensa e estou interessado em cenários adicionais que exigiriam o uso dos cabeçalhos: `Responder a remetente, remetente originalmente de, erros a '
goodguys_activate

Obrigado pelas adições. Espero obter uma compreensão clara do que são os comportamentos esperados do MTA e do que eles são implementados. Além disso, você pode estar interessado neste q: Acabei de publicar no Sec.StackExchange sobre a lista de permissões de e-mail (semelhante ao BATV) security.stackexchange.com/q/41008/396
goodguys_activate

11
+1, por que apenas 4 votos?
Pacerier 23/07

11

O processamento automatizado é um grande motivo. Você deseja enviar saltos / respostas automáticas / erros para serem processados ​​separadamente, caso contrário, essas mensagens desaparecem ou são ignoradas, ou alguma seiva pobre precisa cavá-las. Sim, é possível adicionar um cabeçalho X para processamento, mas a maior parte do tempo salta / etc. não incluirá o email original ou apenas uma parte desconectada e você não poderá obter a fonte.

Por exemplo, digamos que alguém se inscreva no seu site e envie um e-mail agradecendo por se inscrever. Seu MAILFROM e From podem ficar assim:

MAIL FROM: <user-signup-123123123@bounces.example.com>
From: Website X <noreply@example.com>

Dessa forma, o usuário vê o "amigável de" no cliente de email. Mas se o usuário não existir, o MTA enviará a mensagem de devolução para:

user-signup-123123123@bounces.example.com

e um processo automatizado pode facilmente puxar o ID do usuário (a parte 123123123) e a parte do sistema que criou a rejeição (a parte de inscrição) do cabeçalho e excluir / marcar facilmente esse usuário como desativado.


8

O email de: na conversa smtp foi projetado para ser o local para onde os retornos irão. O cabeçalho De: no corpo da mensagem é usado para exibir ao destinatário e como endereço de resposta se o cabeçalho Responder para: não estiver definido.

Os e-mails que não devem gerar devolução devem definir o remetente vazio no envelope; por exemplo, um recibo de retorno normalmente terá: mail from:<>com o nome do usuário no cabeçalho from:.

Outra situação é quando um servidor de correio está usando o BATV para rejeitar devoluções falsas. O e-mail de: estará no formato prvs=tag-value=mailbox@example.com.


Acho que me lembro de ter visto um cabeçalho X para retornos e notificações de falha na entrega. Você sabe quando e como isso é usado?
goodguys_activate

Os cabeçalhos X foram originalmente adicionados como um meio de MUAs e / ou MTAs para colocar metadados personalizados e não são especificados em nenhum padrão, embora alguns se tornem padrões padrões. Você pode estar pensando no tipo mime multipart / report definido na rfc 6522, que foi definido para ajudar o software a classificar as mensagens que são devolvidas automaticamente. Estes ainda serão enviados com um envelope vazio no correio de:
Richard Salts

1

A menos que eu não esteja lendo meus cabeçalhos ou a pergunta corretamente, os e-mails do meu BlackBerry são enviados do servidor BlackBerry e basicamente nenhum dos campos corresponde. Pequena porcentagem de usuários, eu percebo. Eu estive olhando isso recentemente na avaliação do meu servidor de email. Abaixo está um e-mail anonimizado enviado do meu BlackBerry para minha conta do Gmail:

Delivered-To: recipientusername@gmail.com
Received: by 10.50.11.138 with SMTP id q10csp217364igb;
        Wed, 14 Aug 2013 00:18:53 -0700 (PDT)
X-Received: by 10.42.83.84 with SMTP id g20mr4290552icl.10.1376464731205;
        Wed, 14 Aug 2013 00:18:51 -0700 (PDT)
Return-Path: <SRS0=BQ46+U=R3=example.com=senderusername@srs.bis6.us.blackberry.com>
Received: from smtp08.bis6.us.blackberry.com (smtp08.bis6.us.blackberry.com. [74.82.85.8])
        by mx.google.com with ESMTP id lq6si7427361icb.102.2013.08.14.00.18.51
        for <recipientusername@gmail.com>;
        Wed, 14 Aug 2013 00:18:51 -0700 (PDT)
Received-SPF: pass (google.com: domain of SRS0=BQ46+U=R3=example.com=senderusername@srs.bis6.us.blackberry.com designates 74.82.85.8 as permitted sender) client-ip=74.82.85.8;
Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of SRS0=BQ46+U=R3=example.com=senderusername@srs.bis6.us.blackberry.com designates 74.82.85.8 as permitted sender) smtp.mail=SRS0=BQ46+U=R3=example.com=senderusername@srs.bis6.us.blackberry.com
Received: from b15.c8.bise6.blackberry ([192.168.0.115])
    by srs.bis6.us.blackberry.com (8.13.7 TEAMON/8.13.7) with ESMTP id r7E7InfH019786
    for <recipientusername@gmail.com>; Wed, 14 Aug 2013 07:18:49 GMT
Received: from 172.29.201.172 (cmp2.c8.bise6.blackberry [172.29.201.172])
    by b15.c8.bise6.blackberry (8.13.7 TEAMON/8.13.7) with ESMTP id r7E7IlCt013236
    for <recipientusername@gmail.com>; Wed, 14 Aug 2013 07:18:47 GMT
X-rim-org-msg-ref-id: 587275596
Message-ID: <587275596-1376464726-cardhu_decombobulator_blackberry.rim.net-631052459-@b17.c8.bise6.blackberry>
Reply-To: senderusername@example.com
X-Priority: Normal
Sensitivity: Normal
Importance: Normal
Subject: Test
To: "Recipient Name" <recipientusername@gmail.com>
From: senderusername@example.com
Date: Wed, 14 Aug 2013 07:18:45 +0000
Content-Type: text/plain
MIME-Version: 1.0

Test
Sent via BlackBerry by AT&T

Há uma excelente razão para isso - a reescrita do SPF . Se o BlackBerry não estivesse fazendo isso, você receberia muito mais falhas no SPF a partir do seu dispositivo.
precisa saber é o seguinte

Verdade, mas isso ocorre porque o BlackBerry não usa meu servidor para enviar.
Paul
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.