Estou tendo problemas para retransmitir para servidores cujos e-mails são roteados através do mimecast. As conexões estão sendo rejeitadas com a mensagem:
553 This route requires encryption (TLS) - https://community.mimecast.com/docs/DOC-1369#553
Isso me faz pensar que o sendmail, que é configurado com certificados e anuncia STARTTLS quando atua como servidor, não está enviando STARTLS no momento certo (ou de todo). Este é um rastro da falha na transferência:
>>220 zzz.mimecast.com ESMTP; Thu, 16 Jun 2022 11:55:55 +0200
>>> EHLO rigel-170.orion.it
250-zzz.mimecast.com Hello [212.115.64.170]
250-AUTH PLAIN LOGIN
250-STARTTLS
250 HELP
>>> MAIL From:<[email protected]>
250 Sender OK [R9SDNpJCMqeqqffSnRQQeg.de46]
>>> RCPT To:<[email protected]>
553 This route requires encryption (TLS) - https://community.mimecast.com/docs/DOC-1369#553 [R9SDNpJCMqeqqffSnRQQeg.de46]
>>> DATA
503 Illegal command sequence - https://community.mimecast.com/docs/DOC-1369#503 [R9SDNpJCMqeqqffSnRQQeg.de46]
Acrescentarei que o mesmo servidor é executado como um servidor smtps sem problemas (sugerindo que não há problemas no lado do certificado) e que o mailer de envio envia regularmente STARTTLS (posso ver o STARTTLS = cliente nos logs). o único =client que já vi lá (sugerindo que o sendmail não está realmente enviando STARTTLS ao atuar como cliente para outros servidores)
Tentei, sem sucesso, diversas combinações de SRV_Features, Try_TLS, TLS_Clt, TLS_Srv e TLS_Rcpt. A única diretiva TLS que me resta no mapa de acesso até agora é:
Try_TLS: Yes
Também configurei certificados de cliente em sendmail.mc
Não tenho ideia do que tentar a seguir.
EDITAR
Acabei de descobrir o seguinte (ocultando ainda mais o problema).
Eu configurei (por causa de problemas de lista negra) um nome de host/endereço diferente dos padrão (o endereço e o nome do host estão registrados corretamente no DNS). Eu fiz isso com as linhas:
CLIENT_OPTIONS(`M=S,Addr=a.b.c.d')dnl
define(`confDOMAIN_NAME', `fubar.it')dnl
Se essas duas linhas forem comentadas, starttls será emitido conforme o esperado (como visto ao rastrear a sessão SMTP). Isso não parece fazer qualquer sentido.
EDITAR 2: De acordo com os comentários, o culpado é o M=Sbit na linha CLIENT_OPTIONS (que foi extraído de algum lugar há muito tempo). 'S' significa 'desligar STARTTLS', alterá-lo M=sresolve. Para referência, estes são os significados dos sinalizadores nas opções do daemon/cliente a partir do sm 14.4:
ON OFF Meaning
a A Offer the AUTH SMTP extension
b B Offer use of the SMTP VERB command
d D Offer the DSN SMTP extension
e E Offer the ETRN SMTP extension
l L Require the client to authenticate with AUTH
p P Offer the PIPELINING SMTP extension
s S Offer the STARTTLS SMTP extension
v V Verify a client certificate
x X Offer use of the SMTP EXPN ...
Atenciosamente,
Responder1
Pelo que entendi, So sinalizador CLIENT_OPTIONSdesativa STARTTLSo suporte.
CLIENT_OPTIONS(`M=S,Addr=a.b.c.d')dnl