Comprendre "XXXXXXXA" après commande EHLO et " ; 500 #5.5.1 non reconnue" ; après STARTTLS

Introduction

Ce document décrit pourquoi « XXXXXXXA » apparaît dans les échecs de communication du serveur de messagerie et TLS associés à ESA.

Pourquoi voyez-vous « XXXXXXXA » après EHLO et « 500 #5.5.1 commande non reconnue » après STARTTLS ?

TLS échoue pour les messages entrants ou sortants.

Après la commande EHLO, le dispositif de sécurité de la messagerie Cisco (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 sont réussis. 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.

Problème

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.

Motif

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 notamment la correction, l'inspection ESMTP et d'autres.

Solution

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. Puisque ce problème se produit avec des destinations de messagerie distantes qui exécutent PIX, il n'est probablement pas très pratique 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.

Discussion

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.

Recommandation

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 à :

• Sécurité - Produits retirés

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 :

• Sécurité - Produits retirés

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

• Guide d'utilisation du courrier électronique AsyncOS
• Coordonnées de l'assistance GLO
• Assistance et documentation techniques - Cisco Systems

Historique de révision

Révision	Date de publication	Commentaires
1.0	10-Oct-2014	Première publication