Ich habe Probleme beim Weiterleiten an Server, deren E-Mails über Mimecast weitergeleitet werden. Verbindungen werden mit der folgenden Meldung abgelehnt:
553 This route requires encryption (TLS) - https://community.mimecast.com/docs/DOC-1369#553
Das lässt mich vermuten, dass sendmail, das mit Zertifikaten konfiguriert ist und STARTTLS ankündigt, wenn es als Server fungiert, STARTLS nicht zum richtigen Zeitpunkt (oder überhaupt nicht) sendet. Dies ist eine Ablaufverfolgung der fehlgeschlagenen Übertragung:
>>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]
Ich möchte hinzufügen, dass derselbe Server problemlos als SMTP-Server ausgeführt wird (was darauf hindeutet, dass es auf der Zertifikatsseite keine Probleme gibt) und dass der Übermittlungsmailer regelmäßig STARTTLS sendet (ich kann den STARTTLS=Client in den Protokollen sehen). Dies ist jedoch der einzige =Client, den ich dort jemals sehe (was darauf hindeutet, dass Sendmail nicht wirklich STARTTLS sendet, wenn es als Client für andere Server fungiert).
Ich habe vergeblich mehrere Kombinationen von SRV_Features, Try_TLS, TLS_Clt, TLS_Srv und TLS_Rcpt ausprobiert. Die einzige TLS-Direktive, die ich bisher noch in der Zugriffszuordnung habe, ist:
Try_TLS: Yes
Ich habe auch Client-Zertifikate in sendmail.mc konfiguriert
Ich habe keine Ahnung, was ich als nächstes versuchen soll.
BEARBEITEN
Ich habe gerade Folgendes herausgefunden (was die Sache noch komplizierter macht).
Ich hatte (aufgrund von Blacklisting-Problemen) einen anderen Hostnamen/eine andere Adresse als die Standardnamen konfiguriert (sowohl Adresse als auch Hostname sind ordnungsgemäß im DNS registriert). Dies tat ich mit den Zeilen:
CLIENT_OPTIONS(`M=S,Addr=a.b.c.d')dnl
define(`confDOMAIN_NAME', `fubar.it')dnl
Wenn diese beiden Zeilen kommentiert sind, wird starttls wie erwartet ausgegeben (wie beim Verfolgen der SMTP-Sitzung zu sehen ist). Das scheint keinen Sinn zu ergeben.
BEARBEITEN 2: Laut den Kommentaren ist der Übeltäter das M=SBit in der Zeile CLIENT_OPTIONS (das vor Ewigkeiten von irgendwoher kopiert wurde). „S“ bedeutet „STARTTLS ausschalten“, es zu ändern M=sfunktioniert. Zur Referenz sind dies die Bedeutungen der Flags in den Daemon-/Client-Optionen ab 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 ...
Beste grüße,
Antwort1
So wie ich es verstehe, wird die Unterstützung Sdurch die Flagge CLIENT_OPTIONSdeaktiviert STARTTLS.
CLIENT_OPTIONS(`M=S,Addr=a.b.c.d')dnl