O postfix me fornece um endereço "Endereço do remetente rejeitado: preciso de endereço completo"; erros com endereços estranhos

Question

Estou recebendo algumas mensagens de erro como esta:

Jan 28 17:20:47 halk postfix/smtpd[29413]: NOQUEUE:
    reject: RCPT from mail.m2osw.com[138.197.205.139]:
    504 5.5.2 <SRS1=R3xB=m2osw.com==hj4N=ZL=lime.ocn.ne.jp=@com>:
    Sender address rejected: need fully-qualified address;
    from=<SRS1=R3xB=m2osw.com==hj4N=ZL=lime.ocn.ne.jp=@com>
    to=<[email protected]> proto=ESMTP helo=<m2osw.com>

Não tenho certeza se entendi o endereço de "e-mail" encontrado entre os colchetes angulares:

SRS1=R3xB=m2osw.com==hj4N=ZL=lime.ocn.ne.jp=@com

Isso parece uma merda para mim, mas talvez seja uma forma de envolvimento?

O original de parece com isto:

From: western union <"westernunion1."@lime.ocn.ne.jp>

(que é um e-mail de spam claro, mas isso acontece com o não-spam também).

Tanto quanto eu sei que minha configuração funcionou bem antes, mas eu atualizei um dos meus servidores de e-mail para o mais novo postfix (bem Ubuntu 16.04 em vez de 14.04). O servidor de arquivamento foi atualizado há algum tempo.

Esse erro acontece quando eu envio um e-mail do Gmail. Então o Gmail recebe uma rejeição.

A configuração é algo assim:

+------------------+    +------------------+
|                  |    |                  |
| Client           |--->| Main Server      |
|                  |    |                  |
+------------------+    +------------------+
                                |
                                v
                        +------------------+
                        |                  |
                        | Archive Server   |
                        |                  |
                        +------------------+

No servidor principal , o email funciona como esperado. O erro ocorre quando o email chega ao Servidor de arquivamento .

Existe algo que poderia ter mudado que "quebra" o endereço de e-mail de tal forma quando encaminhando de um MTA postfix para outro?

    

Answer 1

Ok, eu encontrei o culpado. Esses endereços de e-mail "estranhos" começam com o SRS, que aponta para o suporte SPIF que postfix pode usar por meio de postsrsd . Há quatro entradas que o autor daemon postsrsd sugere para fazer no seu arquivo postfix/main.cf :

sender_canonical_maps = tcp:localhost:10001
sender_canonical_classes = envelope_sender
recipient_canonical_maps = tcp:localhost:10002
recipient_canonical_classes= envelope_recipient,header_recipient

Claramente, isso gera um envelope do endereço de e-mail. A especificação desse envelope é:

[email protected]

O problema no meu caso era que o nome do domínio após o @ estava sendo gerado dinamicamente. Isso significava tomar o nome completo do host do computador e remover o primeiro nome. Portanto, se eu tiver m2osw.com como o nome do host, postsrsd acabará usando com como o nome do domínio. Em outras palavras, eu acabaria com endereços de e-mail semelhantes a:

...@com

Obviamente, @com não é um nome de domínio válido.

O daemon postsrsd usa algumas definições encontradas no arquivo:

/etc/default/postsrsd

Lá encontramos uma variável chamada SRS_DOMAIN . Ao definir essa variável com o nome de domínio correto:

SRS_DOMAIN=m2osw.com

Os e-mails são envelopados conforme o esperado e os erros desaparecem. (Ou seja, tivemos essa configuração corretamente em nosso antigo "Servidor Principal". Sentimos falta disso ao fazer nossa transferência).

    

Answer 2

Acho que não, o log que você compartilhou mostra que tudo parece OK e o postfix está funcionando bem. Se você precisar de mais informações sobre o que está acontecendo, adicione o seguinte ao main.cf:

error_notice_recipient = [email protected]
delay_notice_recipient = $error_notice_recipient
bounce_notice_recipient = $error_notice_recipient
2bounce_notice_recipient = $error_notice_recipient
#The list of error classes that are reported to the postmaster
notify_classes = bounce, delay, policy, protocol, resource, software

A rejeição é porque uma dessas linhas:

reject_non_fqdn_helo_hostname,
    reject_non_fqdn_recipient

Espero que isso ajude