SMTP_INVALID_COMMAND

[jagoe]

Does anyone have any insight to add to what I've already gleaned about the following?

48806: Sep 22 07:03:16: %FW-3-SMTP_INVALID_COMMAND: Invalid SMTP command (MIME-Versi)(total 1452 chars) from initiator (10.0.0.209:10566)

I see these messages from time to time when an Exchange 2000 server has a stuck message in its queue. The part in the parentheses immediately following "Invalid SMTP command" varies. For instance, on a previous occasion it was (content-cl). Regardless of the text the total character length is always 10 characters.

Additional information: IOS (tm) C806 Software (C806-K9OSY6-M), Version 12.3(1a), RELEASE SOFTWARE (fc1). The problem only seems to occur when the ex2k machine attempts to send mail to a non-esmtp machine. In some cases it reverts to a successful HELO and the session is established. But with some servers even the HELO won't work and the message remains stuck in the queue. I've run a packet sniffer on the line and the packet contents all look normal. Does anyone know why the firewall is flagging supposedly bad smtp commands?

I have not yet put a sniffer on the outside side of the firewall. Does anyone know if the firewall is actually allowing these supposedly bad packets out?

[scoclayton]

Hi,

I would be willing to bet that you have the following configured:

ip inspect name smtp

With this configured, CBAC inspects all SMTP packets for illegal commands. Any packets with illegal commands are dropped, and the SMTP session will hang and eventually time out. An illegal command is any command except for the following legal commands:

DATA

EHLO

EXPN

HELO

HELP

MAIL

NOOP

QUIT

RCPT

RSET

SAML

SEND

SOML

VRFY

For more info, please refer to the following (The Bible for CBAC info):

http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120t/120t5/iosfw2/iosfw2_2.htm

Scott

[jagoe]

Hi Scott,

Thanks for your reply. You are absolutely right, I do have the following configured:

ip inspect name smtp

Additionally I am have read (several times, actually) "The Bible for CBAC" and believe that CBAC is responsible for blocking packets, although as I mentioned I'm still not sure whether it's the outbound or return traffic that's being blocked.

At the foundation I believe there may be a "feature" (read "possible bug") in the CBAC implementation that is incorrectly identifying portions of packet payload as being illegal smtp commands. I've been forunate enough to capture live packets traces during this CBAC event chain. Using snort I've logged the exchange between smtp servers in binary tcpdump format. It strikes me that this would be invaluable real-world data for the Cisco developers responsible for CBAC. Is there an interest in my providing this trace?

Best regards,

Louis

[scoclayton]

Louis,

Absolutely, your trace would be of interest to us. As you mentioned though, it is difficult to tell based on the log messages whether the packets that we blocked were inbound or outbound. In most cases where SMTP inspection is config'ed, there is no way (feasible) sniff the wire on teh outside (assuming some sort of WAN connection). However, if you have ethernet on both sides (or the ability to sniff WAN links), then open a TAC case and give us the info collected. I have been suspecting a "feature" in the SMTP inspection code for sometime but I have never had anyone willing/able to provide the info. Most people just turn off SMTP inspection and move on...sad but understandable.

Scott

[jagoe]

OK Scott, let's move ahead on this. Perhaps it's time to take the dialog offline. Why don't you send me an email message and we can coordinate (i.e. I've never opened a TAC case before and wouldn't know where to begin). I'll be traveling for the next week or so but upon my return I'd like to investigate further. I'll even try to set up a sniffer on the WAN side of the router as I've identified a seemingly consistent/reproducible mail server for raising this event.

Louis

[scoclayton]

For shame, not knowing how to open a TAC case... ;)

Probably a good thing. Anyway, just send me the info directly (sclayton@cisco.com) and if I need to open a TAC case for ya, I will. Happy traveling.

[commandlinekid]

In no way am I saying this is an answer to anyone's question but it DOES provide insight:

1.) 10 years I ran on a 2621 a "routing setup" where "ip inspect name LIST smtp" worked fine.

2.) Switched recently to a connect that required me to use the first IP in the subnet ON their router but still wanted to route so I needed to use BVI. And now I need this command REMOVED or smtp won't work well. 

Just some color.