falha ao receber e-mail para o subdomínio de algum host

Question

Eu configurei recentemente um servidor de e-mail no servidor digitalocean com postfix & pomba. Funciona muito bem para o domínio principal: example.com

Eu também configuro um subdomínio: verify.example.com

Envio e recebimento de trabalhos para ambos. Até que recentemente encontrei um problema com o subdomínio. Um usuário tentou enviar um email para [email protected] de seu servidor. Mas eu nunca recebi essa correspondência.

Aqui está a parte /var/log/mail.log:

postfix/smtpd[2627]: connect from gproxy3-pub.mail.unifiedlayer.com[69.89.30.42]
postfix/policy-spf[2635]: Policy action=PREPEND Received-SPF: pass (userdomain.com: Sender is authorized to use '[email protected]' in 'mfrom' identity (mechanism 'include:hostmonster.com' matched)) receiver=example.com; identity=mailfrom; envelope-from="[email protected]"; helo=gproxy3-pub.mail.unifiedlayer.com; client-ip=69.89.30.42
postfix/smtpd[2627]: warning: connect to mysql server 127.0.0.1: Access denied for user 'UNKNOWN_USER'@'localhost' (using password: YES)
postfix/smtpd[2627]: warning: mysql:/etc/postfix/mysql/virtual_mailbox_maps.cf lookup error for "[email protected]"
postfix/smtpd[2627]: NOQUEUE: reject: RCPT from gproxy3-pub.mail.unifiedlayer.com[69.89.30.42]: 451 4.3.0 <[email protected]>: Temporary lookup failure; from=<[email protected]> to=<[email protected]> proto=SMTP helo=<gproxy3-pub.mail.unifiedlayer.com>
postfix/smtpd[2627]: disconnect from gproxy3-pub.mail.unifiedlayer.com[69.89.30.42]

Observe que, no arquivo de log, ele diz [email protected] , mas o e-mail é enviado para [email protected] .Parece que o e-mail "foi redirecionado 'do subdomínio ao domínio principal. Estou tendo esse problema apenas do servidor desse usuário. Para outros usuários sem tal problema até agora.

Eu tenho MX & Registros CNAME configurados para verify.example.com

    

Answer 1

Desculpe por não ter percebido isso imediatamente, porque esse é o problema:

I've both MX & CNAME records set up for verify.example.com

Os CNAMEs só podem existir como registros únicos e não são combinados com outros registros de recursos. Isso é especificado em RFC 1034 , seção 3.6.2.

A razão pela qual o e-mail quebra especificamente é encontrada na RFC 5321 , seção 5.1:

That domain name, when queried, MUST return at least one address record (e.g., A or AAAA RR) that gives the IP address of the SMTP server to which the message should be directed. Any other response, specifically including a value that will return a CNAME record when queried, lies outside the scope of this Standard. The prohibition on labels in the data that resolve to CNAMEs is discussed in more detail in RFC 2181, Section 10.3.

Quando você alterou o CNAME para um registro A, passou de fazer errado para fazer certo, e é por isso que começou a funcionar.

Por acaso, este é um excelente exemplo do motivo pelo qual ofuscar seu nome de domínio é inútil. Se você tivesse dado o seu nome de domínio real, eu provavelmente teria encontrado o erro apenas verificando sua configuração.