I'm having problems relaying to servers that whise mail is routed through mimecast. Connections are being rejected with the message:
553 This route requires encryption (TLS) - https://community.mimecast.com/docs/DOC-1369#553
This makes me think sendmail, which is configured with certificates and advertises STARTTLS when acting as a server, is not sending STARTLS at the right time (or at all). This is a trace of the failed transfer:
>>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:<rrr@kkk.it>
250 Sender OK [R9SDNpJCMqeqqffSnRQQeg.de46]
>>> RCPT To:<xxx@yyy.com>
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]
I will add that the the same server runs as an smtps server with no issues (suggesting no no problems on the certificate side) and that submission mailer regularly sends STARTTLS (I can see the STARTTLS=client in the logs.) However,that is the only =client I ever see there (suggesting sendmail is not actually sending STARTTLS when acting as a client to other servers)
I have tried, to no avail, several combinations of SRV_Features, Try_TLS, TLS_Clt, TLS_Srv and TLS_Rcpt. The only TLS directive I have left in the access map so far is:
Try_TLS: Yes
I also have configured client certificates in sendmail.mc
I have no idea what to try next.
EDIT
I just found out the following (further clouding the issue).
I had configured (because of blacklisting issues) a hostname/address different from the default ones (both address and hostname are properly registered in the DNS). I did so with the lines:
CLIENT_OPTIONS(`M=S,Addr=a.b.c.d')dnl
define(`confDOMAIN_NAME', `fubar.it')dnl
If these two lines are commented, starttls is issued as expected (as seen by tracing the SMTP session). That does not appear to make any sense.
EDIT 2: As per the comments, the culprit is the M=S bit in the CLIENT_OPTIONS line (that was ripped from somewhere aeons ago). 'S' means 'turn off STARTTLS', changing it in M=s does the trick. For reference, these are the meaning of the flags in daemon/client options as of 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 ...
Best regards,
