Razões legítimas O SMTP “MAIL FROM:” não corresponderá a “From:” Header in DATA

15

Existe algum motivo legítimo para o campo SMTP "MAIL FROM:" não corresponder ao campo "De:" na seção DATA de uma mensagem, além de listas de discussão?

De link :

“Mas, para continuar sua metáfora, 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 esta linha de lógica está aqui: "cortesia para o 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.

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

"Mas se você realmente quer garantir From: e MAIL FROM então você tem que aplicar header_checks para que Return-Path: corresponda From:"

Quais são as implicações disso? Listas de discussão obviamente seriam um problema. Há algum outro uso legítimo de informações de cabeçalho diferentes "MAIL FROM:" e "From:"?

    
por dkovacevic 24.06.2013 / 17:11

4 respostas

17

Existem muitas razões pelas quais os endereços de cabeçalho e envelope de podem não coincidir. A maioria diz respeito aos processos automatizados que enviam e-mail, onde os problemas de entrega precisam ser relatados para um endereço que não é representativo de quem enviou o e-mail, ou quem foi enviado em nome de ou quem deve ser respondido. Listas de discussão como você apontou são um bom exemplo.

A principal razão pela qual uma mensagem enviada do cliente de e-mail de um usuário pode diferir dos endereços é o e-mail encaminhado. O conteúdo do e-mail deve ser razoavelmente fiel ao original, mas, no caso de erros de entrega, eles devem ser relatados ao usuário que encaminhou o e-mail, não ao remetente original.

Além do cabeçalho SMTP, há uma variedade de cabeçalhos MIME usados por vários programas para tentar distinguir entre o remetente original e o remetente intermediário e / ou o endereço preferencial para relatar erros.Eg Responder para, Remetente, Originalmente-From, erros-para, etc, etc, cada um com diferentes sematics. Algumas delas têm suporte a padrões, enquanto muitas outras não, mas podem estar em uso de qualquer maneira. A maneira como vários programas de correio se comportam na prática varia consideravelmente.

Se é aconselhável uma maneira de endereçar e-mails é um assunto diferente de ser "legítimo" como você pergunta. Se você está considerando legitimidade aqui em termos de algo como política para lidar com spams potenciais, então não, eu não acho que você será capaz de fazer uma distinção simples desta forma.

Pense na assinatura de email do DKIM e na autenticação SPF de servidores de email para domínios de email. Se você estiver enviando muitos e-mails, pode ser importante poder autenticar seus e-mails dessas maneiras, e isso pode ter implicações no endereçamento de e-mails de cabeçalhos, já que você só pode autenticar e-mails relacionados a domínios para os quais você tem autoridade .

-

Estendido a pedido:

Um cabeçalho MIME 'Reply-To' direciona um MUA (Mail User Agent, geralmente o cliente de e-mail de uma pessoa) a enviar respostas para um endereço diferente, em vez do endereço MIME 'From'. Isso não é usado por um MTA (agente de transporte de email) 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 honrarão, portanto, é um mecanismo inferior para definir o endereço do Envelope SMTP, mas há muitas circunstâncias em que talvez seja possível definir os Cabeçalhos MIME em uma mensagem, mas não o endereço SMTP Envelope de. Por exemplo, software rodando em um ambiente de hospedagem compartilhada pode se encontrar nesta situação.

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

'Original-From' é usado por alguns softwares MUA ao encaminhar mensagens, com o endereço do remetente sendo usado para o cabeçalho 'De'. Outros MUAs deixarão o endereço From sozinho e usarão um cabeçalho "Resent-From". Se os MUAs que recebem esses e-mails de vários cabeçalhos interpretam os cabeçalhos de maneira útil, ou até mesmo exibem esses cabeçalhos é bastante variável. Ao responder a um e-mail que foi encaminhado a você, a quem a resposta deve ir 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 contraste, a semântica do Envelope é muito mais definida. Normalmente, existe uma posição strong 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 e-mail (por exemplo, ver SPF e os padrões DMARC emergentes), há pressão para que a posição seja degradada. Mecanismos de longa duração, como Erros - Também conflitaram com a noção de MTAs que não estão olhando para o conteúdo do cabeçalho, o que faz parte do motivo pelo qual esses mecanismos sempre foram aplicados de maneira inconsistente. Filosofias de autores de software variam.

Você pode achar útil examinar o link , mas lembre-se de que as práticas reais da multidão de software de correio lá fora varia de maneiras que não são necessariamente abençoados por padrões.

Não há problema em tentar chegar a uma filosofia clara de como você acha que o e-mail deve ser usado, mas não espere que todos façam as coisas como você acha que deveriam.

    
por 14.08.2013 / 15:12
9

O processamento automatizado é um grande motivo. Você quer ser capaz de enviar quaisquer bounces / autoreplies / errors para serem processados separadamente, caso contrário essas mensagens desaparecem, ou são ignoradas, ou algum pobre coitado tem que cavar através delas. Sim, adicionar um cabeçalho X para processamento é possível, mas a maior parte do tempo é devolvida / etc. não incluirá o email original ou apenas uma parte mutilada e você não poderá obter a fonte.

Por exemplo, digamos que alguém se inscreva em seu website e envie um e-mail dizendo obrigado por se inscrever. Seu MAILFROM e From podem ser assim:

MAIL FROM: <[email protected]>
From: Website X <[email protected]>

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

[email protected]

e um processo automatizado pode facilmente extrair o userid (a parte 123123123) e a parte do sistema que criou a devolução (a parte -signup) do cabeçalho e facilmente excluir / marcar esse usuário como desativado.

    
por 14.08.2013 / 15:54
7

O e-mail de: na conversa smtp é projetado para ser o lugar onde as rejeições irão O cabeçalho De: no corpo da mensagem é usado para exibir o destinatário e como o endereço de resposta se o cabeçalho Responder para: não estiver definido.

E-mails que não devem gerar um salto devem definir o remetente vazio no envelope, por Por exemplo, um recibo de recebimento geralmente terá: mail from:<> com o nome do usuário no de: cabeçalho.

Outra situação é quando um servidor de e-mail está usando o BATV para rejeitar retornos falsificados. O email de: estará no formato [email protected].

    
por 14.08.2013 / 09:56
1

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

Delivered-To: [email protected]
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 <[email protected]>;
        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 <[email protected]>; 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 <[email protected]>; 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: [email protected]
X-Priority: Normal
Sensitivity: Normal
Importance: Normal
Subject: Test
To: "Recipient Name" <[email protected]>
From: [email protected]
Date: Wed, 14 Aug 2013 07:18:45 +0000
Content-Type: text/plain
MIME-Version: 1.0

Test
Sent via BlackBerry by AT&T
    
por 18.08.2013 / 22:21

Tags