Eu tenho um servidor doméstico e atualizei a unidade do sistema para um SSD, como estava em uma combinação de USB e HDD para/home e/var. Como o USB estava em uma versão anterior do Debian, fiz uma nova instalação, que também me atualizou para a versão 4.95 do EXIM, anteriormente eu estava na 4.94.2.
Apesar da mesma configuração do smarthost, para usar o servidor SMTP do meu ISP, ele não usa mais TLS e dá erro de validação.
/var/log/exim4/mainlog:
2022-04-12 03:30:25 1ne6I7-000AHw-MF TLS session: (certificate verification failed): delivering unencrypted to H=<DOMAIN> [<IP>] (not in hosts_require_tls)
O e-mail ainda é aceito sem criptografia, mas agora o e-mail dos cron jobs está sendo sinalizado pelo meu ISP como spam. A única mudança é que as mensagens são um Receivedcabeçalho que passou de with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2)apenas with esmtp (Exim 4.95). Então, presumivelmente, essa diferença é o que o sinaliza para atenção extra.
Eu estava usando a mesma chave autoassinada e certificado (com carimbo de data e hora de 2013) da instalação anterior. Também tentei gerar um novo par com falta de efeito semelhante.
Depois de procurar conselhos on-line, foi sugerido usar uma configuração letsencrypt para que pudesse ser validado. Já uso isso, mas causou o mesmo comportamento no EXIM.
Esta é a minha configuração
/etc/exim4/update-exim4.conf.conf:
dc_eximconfig_configtype='smarthost'
dc_other_hostnames='<LOCAL DOMAIN>'
dc_local_interfaces='127.0.0.1 ; ::1'
dc_readhost=''
dc_relay_domains=''
dc_minimaldns='false'
dc_relay_nets=''
dc_smarthost='<ISP DOMAIN>:587'
CFILEMODE='644'
dc_use_split_config='true'
dc_hide_mailname='false'
dc_mailname_in_oh='true'
dc_localdelivery='maildir_home'
/etc/exim4/etc/exim4/conf.d/main/00_local_settings:
MAIN_TLS_ENABLE = yes
MAIN_TLS_CERTIFICATE = /etc/letsencrypt/live/<LOCAL DOMAIN>/fullchain.pem
MAIN_TLS_PRIVATEKEY = /etc/letsencrypt/live/<LOCAL DOMAIN>/privkey.pem
/etc/letsencrypt/archive/<DOMÍNIO LOCAL>/*15.*
-rw-r--r-- 1 root Debian-exim 1870 Mar 28 00:48 /etc/letsencrypt/archive/<LOCAL DOMAIN>/cert15.pem
-rw-r--r-- 1 root Debian-exim 3749 Mar 28 00:48 /etc/letsencrypt/archive/<LOCAL DOMAIN>/chain15.pem
-rw-r--r-- 1 root Debian-exim 5619 Mar 28 00:48 /etc/letsencrypt/archive/<LOCAL DOMAIN>/fullchain15.pem
-rw------- 1 root Debian-exim 1708 Mar 28 00:48 /etc/letsencrypt/archive/<LOCAL DOMAIN>/privkey15.pem
Também tenho /etc/exim4/passwd.clientum arquivo com meus detalhes de login SMTP e que obviamente está funcionando para enviar e-mails.
é um domínio que aponta para meu endereço IP residencial.
As entradas para as chaves letsencrypt em 00_local_settings apontam para seus links simbólicos que vão para as versões atuais. Nestes eu mudei a propriedade do grupo para que o EXIM possa ver a chave privada, mas deixei as permissões em paz.
Minha configuração de trabalho anterior era a mesma, mas com os arquivos autoassinados exim.crte exim.keyem /etc/exim4, e sem as duas últimas linhas em meu arquivo 00_local_settings.
Também tentei copiar os arquivos letsencrypt /etc/exim4e nomeá-los exim.certcom exim.keyas mesmas permissões de 640 e nada em 00_local_settings, mas isso não mudou nada.
O que é particularmente irritante é que, como teste final, acabei de excluir as chaves sem nenhuma configuração para ver o que aconteceria. Recebi o mesmo erro, por isso não consigo dizer se há algum problema com as chaves que usei ou se simplesmente não as vejo.
Responder1
Continuei pesquisando e encontrei uma espécie de resposta. Não estava claro para mim qual certificado estava sendo verificado, presumi o meu, mas percebi que poderia ser o do servidor SMTP remoto.
Adicionar a entrada abaixo para /etc/exim4/etc/exim4/conf.d/main/00_local_settingsdesabilitar a verificação permite que o TLS seja usado.
REMOTE_SMTP_SMARTHOST_TLS_VERIFY_HOSTS = !*
Isto pode ser confirmado no cabeçalho da mensagem que agora mostra que ela foi recebidawith esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95)
Presumo que isso seja o que estava acontecendo antes e que o Debian ou o Exim mudaram o padrão para exigir verificação desde minha configuração inicial.
Presumivelmente, se o servidor remoto usar um certificado gerado automaticamente, ele não poderá ser verificado?