O erro de autenticação não foi um resultado direto da incompatibilidade entre / etc / mailname e o nome comum (CN) no certificado SSL, foi devido à configuração incorreta do servidor de correio; no entanto, depois que o servidor de e-mail funcionou, a incompatibilidade de CN causou avisos de segurança quando enviei um e-mail para uma conta do Gmail. Eu criei um novo certificado SSL para que o CN correspondesse ao / etc / mailname e os avisos de segurança relacionados a esse problema fossem embora (embora eu ainda esteja recebendo avisos de segurança relacionados à mensagem não estar criptografada).
Lição aprendida: o CN no certificado SSL usado pelo servidor de email deve corresponder ao nome do servidor de email em oposição ao nome de um host virtual hospedado na mesma máquina que o servidor de email (incluí o servidor de email e todos os meus hosts virtuais no mesmo certificado SSL, mas listei o servidor de e-mail primeiro para obter o CN configurado corretamente).
EDITAR:
Além da lição aprendida sobre a pergunta original, também aprendi o seguinte durante o processo de configuração do meu servidor de e-mail:
-
"Além disso, para alguns serviços de e-mail, como o gmail - você precisa ter DNS reverso configurado no IP do servidor de e-mail e esse nome também precisa corresponder ao nome de e-mail" -ivanivan
-
Eu tinha um registro DNS PTR reverso para meu endereço IPv4, mas meu registro IPv6 PTR estava errado e tive que atualizá-lo. Na verdade, sem o registro de PTR adequado, os e-mails que enviei para o gmail não estavam sendo entregues. Eles estavam retornando ao remetente com informações sobre as diretrizes de envio do IPv6.
-
O e-mail ainda estava descriptografado. Consulte E-mails enviados não criptografados para minha configuração de postfix e como resolvi o problema de criptografia .