Isso é muito mais uma questão em partes, e eu entendo como tal. Eu usei sendmail como meu MTA preferido por algumas décadas, mas não posso afirmar ser um expert nele (ou seja, não sou Eric Allman).
verifymsg=unable to get local issuer certificateI take this to mean that at least one cause of the verification failure is that sendmail can't find a certificate for the local machine it's running on?
Isso parece ser uma mensagem OpenSSL, em vez de uma MTA , e pelo que entendi isso significa que o aplicativo de verificação não consegue obter cópia local do certificado do emissor. Em outras palavras, o sendmail não tem acesso a um pacote de certificados que inclui o certificado raiz para quem emitiu o certificado do servidor remoto. Lembre-se de que o Linux não oferece um serviço centralizado de gerenciamento de certificados, portanto, cada aplicativo deve lançar seu próprio pacote. No meu caso, eu dei acesso ao sendmail para um pacote de certificado com o seguinte código m4:
define('confCACERT', '/etc/pki/tls/certs/ca-bundle.with.intermediate.crt')dnl
I was hoping to see with ESMPTSA but I would guess that the certificate verification failure caused the 'S' to be surpressed.
Acho que o palpite está errado. RFC2821 e 2822 são bastante elásticos quanto ao formato de um cabeçalho Received: e não consigo encontrar nada que distinga entre ESMTPA e ESMPTSA (sic). Todos os meus cabeçalhos mostram linhas como:
Received: from example.com (example.com [80.70.90.61])
by lory.teaparty.net (8.14.4/8.14.4) with ESMTP id u6G25OXi006577
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL)
for <[email protected]>; Sat, 16 Jul 2016 03:05:24 +0100
Para entender o que o MTA do seu receptor significa por ESMTPA , você teria que descobrir qual é esse MTA e ler a documentação. Até que você tenha feito isso, eu não acho que você pode ler muito nessa coleção de cartas.
Can I avoid starttls
verify=failwhen server hostname does not match certificate
Eu não acho que você pode. A ideia fundmental por trás do SSL é que (a) o nome do host ao qual você se conecta (b) oferece um certificado assinado por um terceiro confiável (c) com esse nome de host no campo CN ou SAN. Se alguma dessas propriedades não for atendida, é certo que o SSL observe que não é possível verificar a identidade do par.
Você não deve ler muito sobre isso; certificados auto-assinados ainda são muito comuns no tratamento de email. Dos meus últimos e-mails protegidos por TLS em 1919 enviados / recebidos, 1764 envolveu um par cuja identidade não pôde ser verificada por algum motivo, enquanto apenas 155 puderam. Você mesmo está executando com um certificado autoassinado; você deve, portanto, ficar feliz que a maioria das pessoas não se importe com a cadeia de confiança nos pares TLS SMTP!