Introduction
Ce document explique pourquoi « XXXXXXXA » s'affiche dans la communication du serveur de messagerie et les défaillances TLS associées à l'appliance de sécurisation de la messagerie Cisco (ESA).
Pourquoi voyez-vous XXXXXXXA après EHLO et "500 #5.5.1 command not detected" après STARTTLS ?
TLS échoue pour les messages entrants ou sortants.
Après la commande EHLO, l'ESA répond à un serveur de messagerie externe avec :
250-8BITMIME\
250-SIZE 14680064
250 XXXXXXXA
Après la commande "STARTTLS" dans la conversation SMTP, l'ESA répond à un serveur de messagerie externe avec :
500 #5.5.1 command not recognized
Les tests internes de STARTTLS ont réussi. Cela signifie que lorsque vous contournez le pare-feu, STARTTLS fonctionne correctement, comme les connexions STARTTLS avec les serveurs de messagerie locaux ou les tests d'injection Telnet.
Le problème se produit généralement lorsque vous utilisez un pare-feu Cisco Pix ou Cisco ASA lorsque SMTP Packet Inspection (SMTP et ESMTP Inspection, SMTP Fixup Protocol) et la commande STARTTLS ne sont pas autorisés dans le pare-feu.
Les versions de pare-feu Cisco PIX antérieures à 7.2(3) qui utilisent les différents protocoles de sécurité ESMTP mettent fin à des connexions de manière incorrecte en raison d'un bogue dans l'interprétation des en-têtes dupliqués. Les protocoles de sécurité ESMTP incluent « fixup », « ESMTP inspect », etc.
Désactivez toutes les fonctions de sécurité ESMTP dans PIX, ou mettez à niveau PIX vers 7.2(3) ou ultérieur, ou les deux. Comme ce problème se produit avec les destinations de messagerie distantes qui exécutent PIX, il peut être difficile de le désactiver ou de recommander de le désactiver. Si vous avez la possibilité de faire une recommandation, une mise à niveau du pare-feu devrait résoudre ce problème.
Certains problèmes, pas tous, sont dus à l'inclusion d'en-têtes de message dans d'autres en-têtes, notamment les en-têtes de signature pour les clés de domaine et les clés de domaine pour le courrier identifié. Bien qu'il y ait encore d'autres circonstances dans lesquelles PIX termine une session SMTP de manière incorrecte et provoque des échecs de remise, la signature DK et DKIM est une cause connue. Désactiver temporairement DK ou DKIM pourrait résoudre ce problème pour le moment, mais la meilleure solution est que tous les utilisateurs PIX mettent à niveau ou désactivent ces fonctionnalités de sécurité.
Cisco recommande à tous les clients de continuer à signer des messages avec DKIM et d'envisager d'utiliser cette fonctionnalité si ce n'est déjà fait.
Pour l'inspection SMTP et ESMTP (PIX/ASA 7.x et versions ultérieures), reportez-vous à :
/c/en/us/support/docs/security/pix-500-series-security-appliances/69374-pix7x-mailserver.html
Configuration TLS ESMTP :
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
Pour le protocole de correction SMTP, consultez :
http://www.cisco.com/en/US/docs/security/pix/pix62/configuration/guide/fixup.html
Vous pouvez afficher les paramètres explicites (configurables) du protocole de correction à l'aide de la commande show fixup. Les paramètres par défaut des protocoles configurables sont les suivants :
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
Informations connexes
Commentaires