Isenção de responsabilidade:Eu li algumas das perguntas e artigos aqui e em outros lugares que tratam da reescrita de cabeçalhos do Sendmail. Não encontrei uma resposta para a pergunta abaixo porque a outra pergunta está relacionada principalmente areescrevendocabeçalhos (em vez de adicioná-los), e quase todos eles estão relacionados asaídamensagens e o enveloperemetente(em vez do destinatário do envelope).
Tendo dito isto:
Estou executando um servidor de e-mail, usando o Sendmail 8.14.4 no Debian jessie.
Existem alguns endereços de destinatários de e-mail que são mapeados para a mesma conta de usuário do sistema operacional. Quando o respectivo usuário do sistema operacional lê as mensagens, ele não consegue determinar para qual endereço de e-mail as mensagens foram originalmente enviadas.
Portanto, gostaria que o Sendmail adicionasse um cabeçalho personalizado contendo o(s) destinatário(s) do envelope a todas as mensagens de e-mail recebidas.
Acho que poderia explicar melhor meu problema com um exemplo:
Suponha que eu tenha dois endereços de e-mail [email protected]
e [email protected]
. Ambos são mapeados para a conta de usuário do sistema operacional offers
. Isso funciona até agora: O usuário do sistema operacional offers
, ao buscar seu e-mail, recebe todas as mensagens enviadas para [email protected]
e [email protected]
.
O problema agora é que ele não consegue determinar para qual endereço de e-mail cada mensagem foi originalmente enviada. Isso significa: embora ele veja todas as mensagens que foram enviadas para ambos os endereços de e-mail, ele não consegue dizer se uma determinada mensagem foi enviada originalmente para [email protected]
ou para [email protected]
.
Portanto, gostaria de adicionar um cabeçalho personalizado a cada mensagem recebida, talvez algo assim: X-Envelope-Recipient: <Original envelope recipient>
.
Qual seria a maneira mais fácil de fazer isso?
Era uma vez, escrevi algumas regras personalizadas simples para o Sendmail. Mas quase 15 anos se passaram desde então, então eu gostaria de evitar isso e, portanto, espero que haja uma solução fácil ou que alguém possa me indicar a direção certa. Para ser honesto, escrever um milter para resolver meu problema atualmente me parece mais fácil do que reaprender a sintaxe das regras do Sendmail...
EDITAR 1
Conforme solicitado por @AnFi, aqui está a definição do mailer local de sendmail.cf:
Mlocal, P=/usr/lib/sm.bin/mail.local, F=lsDFMAw5:/|@qPSXnz9, S=EnvFromSMTP/HdrFromL, R=EnvToL/HdrToL,
T=DNS/RFC822/SMTP,
A=mail.local -l -h inbox
Responder1
Sua pergunta é abordada por Sendmail.org FAQ 3.29
3.29 Como posso adicionar um cabeçalho especificando o destinatário real quando vários usuários em um domínio virtual acessam uma única caixa de correio?
Versão curta: Use virtusertable e~offers/.procmailrc
tabela virtual:
[email protected] offers+offer1
[email protected] offers+offer2
~offers/.procmailrc
deve obter "mais detalhes" em $1
.
OU
Você pode usar $h (definido como +detail) em cabeçalhos personalizados
Aviso: você obterá/processará duas cópias de uma mensagem endereçada a ambos [email protected]
e[email protected]
Responder2
O que você sugere seria contra o protocolo SMTP: há razões legítimas para adicionar endereços ao RCPT TO
comando, apesar de eles não existirem nos cabeçalhos To:
ou , ou sejaCc:
RFC 5321 7.2.Cópias "cegas" (a ênfase é minha):
Os endereços que não aparecem na seção do cabeçalho da mensagem podem aparecer nos comandos RCPT para um servidor SMTP por vários motivos. Os dois mais comuns envolvem o uso de um endereço postal como um "explodidor de lista" (um único endereço que se transforma em vários endereços) e o aparecimento de "cópias ocultas". Especialmente quando mais de um comando RCPT está presente, e para evitar anular alguns dos propósitos destes mecanismos,Clientes e servidores SMTP NÃO DEVEM copiar o conjunto completo de argumentos de comando RCPT na seção de cabeçalho, seja como parte dos campos de cabeçalho de rastreamento ou como campos de cabeçalho informativos ou de extensão privada. Como esta regra é frequentemente violada na prática e não pode ser aplicada, os sistemas de envio SMTP que estão cientes do uso de "coco" PODEM achar útil enviar cada cópia oculta como uma transação de mensagem separada contendo apenas um único comando RCPT.
Não há relacionamento inerente entre endereços "reversos" (de comandos MAIL, SAML, etc.) ou "encaminhados" (RCPT) na transação SMTP ("envelope") e os endereços na seção de cabeçalho. Os sistemas receptores NÃO DEVEM tentar deduzir tais relacionamentos e usá-los para alterar a seção do cabeçalho da mensagem para entrega. O popular
Apparently-to
campo de cabeçalho é uma violação deste princípio, bem como uma fonte comum de divulgação não intencional de informações e NÃO DEVE ser usado.
O cabeçalho não recomendado Apparently-to
é controlado com a opção NoRecipientAction=action
.
Defina o comportamento quando não houver cabeçalhos de destinatário ( ou
To:
) na mensagem para ação:Cc:
Bcc:
none
deixa a mensagem inalterada,add-to
adiciona umTo:
cabeçalho com os destinatários do envelope,add-apparently-to
adiciona umApparently-To:
cabeçalho com os destinatários do envelope,add-bcc
adiciona umBcc:
cabeçalho vazio eadd-to-undisclosed
adiciona uma leitura de cabeçalho'To: undisclosed-recipients:;'
.
Observe que normalmente o endereço do destinatário original já está no cabeçalho To:
ou Cc:
. Ele não deve ser modificado para o nome da conta do usuário offers
, portanto está oculto [email protected]
ou [email protected]
oculto. Reescrever cabeçalhos tornou-se ainda mais perigoso, pois também pode quebrar assinaturas DKIM. O único caso de uso razoável é a reescrita de endereço para correspondência de origem local ( user
to [email protected]
).
Adicionar uma lista de todos RCPT TO
os endereços violaria o protocolo, mas na verdade você simplesmente precisa doúnico RCPT TO
endereço originalpara o usuário ao qual o e-mail foi entregue. Não sei como conseguir isso com o Sendmail, masPós-fixo(com a configuração padrão)adiciona umX-Original-To:
cabeçalho contendo exatamente isso e, adicionalmente, um Delivered-To:
cabeçalho contendo a caixa de correio de destino interna ( [email protected]
).