Os servidores SMTP durante a comunicação entre servidores (STMP) e servidores (SMTP) são geralmente obrigados a copiar MAIL FROM da sessão cliente-servidor? Verifiquei explicitamente se os servidores de alguns provedores de e-mail realmente exibem esse comportamento, mas não parece ser um requisito imposto porhttps://datatracker.ietf.org/doc/html/rfc5321. Além disso, não sei quão popular é essa prática (se não for um padrão).
Atualização para ser mais específico: estou interessado principalmente no caso de uma mensagem de e-mail muito comum, de pessoa para pessoa, domínios em dois servidores diferentes.
Responder1
Os servidores são obrigados a manter o caminho de retorno aberto, a forma mais fácil de o fazer é copiar o MAIL FROM:endereço original e reutilizá-lo na transmissão SMTP de saída, mas esta não é a única forma de satisfazer esse requisito.
Geralmente eles fazem isso, mas alguns servidores realizam outras ações, como implantarBATV,SRSou alguma outra forma deVERP.
Como tal, é seguro esperar que um e-mail endereçado ao suposto remetente chegue à entidade responsável pela criação da mensagem, mas possivelmente através de um ou mais intermediários que restaurem o endereço do remetente SMTP anterior.
Responder2
ORFC 5321, 3.3diz para que MAIL FROM:<reverse-path>serve:
A
<reverse-path>parte do primeiro ou único argumento contém a caixa de correio de origem (entre colchetes "<" e ">"), que pode ser usada para relatar erros (consulteSeção 4.2para uma discussão sobre relatórios de erros).
Ocampos originadoresnos cabeçalhos do formato de mensagem da Internet (RFC 5322, 3.6.2) têm propósitos mais específicos para distinguir o autor ( From:) deo agente responsável pela transmissão real da mensagem( Sender):
Por exemplo, se uma secretária enviasse uma mensagem para outra pessoa, a caixa postal da secretária apareceria no
Sender:campo " " e a caixa postal do próprio autor apareceria noFrom:campo " ".
A RFC 5321remetente do envelopetem apenas uma finalidade técnica. É típico emencaminhamento de correioelista de discussãocenários para reescrever para MAIL FROMcorresponder ao domínio/servidor de encaminhamento ou ao operador da lista de discussão. Isso tem dois benefícios:
- Os relatórios de erros serão retornados ao operador da lista de discussão, que deverá cuidar da remoção dos endereços errados da lista.
- Reescrever o remetente do envelope não viola a política SPF do domínio original (Shevek (2004):O esquema de reescrita do remetente).
Por outro lado, tais práticas são ligeiramente contraRFC 5321, 3.7.5:
3.7.5. Envelopes em gateway
Da mesma forma, ao encaminhar uma mensagem de outro ambiente para a Internet, o gateway DEVE definir o caminho de retorno do envelope de acordo com um endereço de retorno da mensagem de erro, se fornecido pelo ambiente externo. Se o ambiente externo não tiver um conceito equivalente, o gateway deverá selecionar e usar a melhor aproximação, com o endereço do originador da mensagem como o padrão de último recurso.
Não vejo isso como problema, pois o protocolo SMTP não foi atualizado (exceto os códigos de resposta SMTP 521 e 556,RFC 7504) desde 2008, mas as práticas, incluindo a prevenção da falsificação de e-mails, evoluíram desde então.
Responder3
MAIL FROM:<reverse-path>como o nome do parâmetro sugere, isso é usado se o servidor precisar "enviar de volta" o e-mail, como erro ou outros problemas, e não precisa ser o mesmo que o remetente do e-mail original.
Muitos servidores validam este campo e o utilizam para spam, mas não há requisitos para isso.