"XXXXXXXA" verstehen nach EHLO und "500 #5.5.1 Befehl nicht erkannt" nach STARTTLS

Einleitung

In diesem Dokument wird erläutert, warum "XXXXXXXA" bei der Mailserver-Kommunikation und TLS-Ausfällen im Zusammenhang mit der ESA auftritt.

Warum wird "XXXXXXXA" nach EHLO und "500 #5.5.1 Befehl nicht erkannt" nach STARTTLS angezeigt?

TLS schlägt bei ein- und ausgehenden Nachrichten fehl.

Nach dem EHLO-Befehl antwortet die Cisco Email Security Appliance (ESA) auf einen externen Mailserver mit:

250-8BITMIME\
250-SIZE 14680064
250 XXXXXXXA

Nach dem Befehl STARTTLS in der SMTP-Konversation antwortet die ESA auf einen externen Mailserver mit:

500 #5.5.1 command not recognized

Interne Tests für STARTTLS sind erfolgreich. Das bedeutet, dass STARTTLS beim Umgehen der Firewall einwandfrei funktioniert, z. B. STARTTLS-Verbindungen mit den lokalen Mail-Servern oder Telnet-Injection-Tests.

Problem

Das Problem tritt in der Regel dann auf, wenn Sie eine Cisco Pix- oder Cisco ASA-Firewall verwenden, wenn SMTP-Paketprüfung (SMTP- und ESMTP-Prüfung, SMTP-Fixup-Protokoll) und der STARTTLS-Befehl in der Firewall nicht zulässig ist.

Ursache

Cisco PIX-Firewall-Versionen vor 7.2(3), die die verschiedenen ESMTP-Sicherheitsprotokolle verwenden, beenden Verbindungen aufgrund eines Fehlers bei der Interpretation doppelter Header falsch. Die ESMTP-Sicherheitsprotokolle umfassen Fixup, ESMTP-Inspektion und andere Protokolle.

Lösung

Deaktivieren Sie alle ESMTP-Sicherheitsfunktionen in PIX, oder aktualisieren Sie PIX auf 7.2(3) oder höher, oder beides. Da dieses Problem bei Remote-E-Mail-Zielen auftritt, auf denen PIX ausgeführt wird, ist es wahrscheinlich nicht sehr praktisch, diese Option zu deaktivieren oder zu empfehlen. Wenn Sie die Möglichkeit haben, eine Empfehlung abzugeben, sollte ein Firewall-Upgrade dieses Problem lösen.

Diskussion

Einige, nicht alle, der Probleme sind auf die Aufnahme von Nachrichten-Headern in andere Header zurückzuführen, insbesondere die Signatur-Header für Domain Keys und Domain Keys Identified Mail. Es gibt noch andere Umstände, unter denen PIX eine SMTP-Sitzung falsch beendet und Lieferfehler verursacht. Die DK- und DKIM-Signierung ist jedoch eine bekannte Ursache.

Empfehlung

Eine vorübergehende Deaktivierung von DK oder DKIM könnte dieses Problem vorerst lösen, aber die beste Lösung ist, dass alle PIX-Benutzer diese Sicherheitsfunktionen aktualisieren oder deaktivieren.

Cisco empfiehlt, dass alle Kunden weiterhin Nachrichten mit DKIM unterzeichnen und die Verwendung dieser Funktion in Betracht ziehen, wenn dies nicht bereits der Fall ist.

Informationen zu SMTP- und ESMTP-Inspektionen (PIX/ASA 7.x und höher) finden Sie unter:

• Sicherheit - Produkte im Ruhestand

ESMTP TLS-Konfiguration:

pix(config)#policy-map global_policy
pix(config-pmap)#class inspection_default
pix(config-pmap-c)#no inspect esmtp
pix(config-pmap-c)#exit
pix(config-pmap)#exit

Informationen zum SMTP-Fixup-Protokoll finden Sie unter:

• Sicherheit - Produkte im Ruhestand

Sie können die expliziten (konfigurierbaren) Fixup-Protokolleinstellungen mit dem Befehl show fixup anzeigen. Die Standardeinstellungen für konfigurierbare Protokolle sind wie folgt:

show fixup
 fixup protocol ftp 21
 fixup protocol http 80
 fixup protocol h323 1720
 fixup protocol rsh 514
 fixup protocol smtp 25
 fixup protocol sqlnet 1521
 fixup protocol sip 5060

Zugehörige Informationen

• AsyncOS E-Mail Benutzerhandbuch
• GLO Support - Kontaktinformationen
• Technischer Support und Dokumentation für Cisco Systeme

Revisionsverlauf

Überarbeitung	Veröffentlichungsdatum	Kommentare
1.0	10-Oct-2014	Erstveröffentlichung