Inspect ESMTP

Answered Question
Feb 27th, 2007

Hello,

How you explain that we you apply in configuration command inspect esmtp with pix version 7(2)1, there is some trouble with mail.

I'm using exchange server.

Thank you a lot.

I have this problem too.
0 votes
Correct Answer by oxys about 9 years 6 months ago

In 7.2.x (including the latest 7.2.2 interim releases) there are bugs related to SMTP/ESMTP inspection. PIX inspection engine drops connections if it finds a registered header name, as "Content-type", inside another header of any kind. This can happen if you use SpamAssassin and configure it to save reports inside e-mail header, or a remarkable case is Gmail which uses control headers containing other header names as keywords.

The problem is that RFCs do not forbid the use of a header name inside another header, but PIX/ASA Os 7.2.x incorrectly detects this behaviour as "malicious" because it sees a duplicate header. So it's the PIX that is wrong, not the messages. I opened a TAC case for this bug about one month ago.

The bug is now recognized as CSCsh33982, a level 2 bug. If you look in the Bug Toolkit you'll find the bug and you'll see that it is fixed in version 7.2(2)12 and 8.x. OS 7.2(2)12 is an interim release, but it is not public. Actually, today I installed it and I have found that the bug is not fully fixed: sometimes Gmail inserts two headers with the same keywords inside a message and the ASA/PIX still drops these messages. A new bug has been recognized: CSCsi01498.

So, at the moment, the only correct suggestion I can give you is to disable SMTP/EMSTP inspection if you use PIX/ASA OS 7.2.x. At least remove it for the traffic originated by or directed to your mail server if you don't want to loose messages.

Another note: serious modern e-mail servers allow you to configure security features for their SMTP service comparable or even better than those provided by PIX inspection. Even MS Exchange can be configured properly.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (4 ratings)
Loading.
fargier Tue, 02/27/2007 - 06:46

I believed that this problem was corrected with pix version 7.

daviddtran Tue, 02/27/2007 - 06:49

I am running version 7.2(2) and my exchange

server is win2k3 w/ service pack 1 behind the

firewall and I am having intermittent issue

with mail until I do "no fixup protcol smpt 25"

and the issue goes away.

David

fargier Tue, 02/27/2007 - 07:05

I have done the same to correct this problem. But i would like to know why ?? Some smtp doesn't respect RFC ?

sebastan_bach Tue, 02/27/2007 - 07:38

hi all in the new ios. pix or ur asa can inspect EMSTP traffic to check for RFC compliance. now ur windows smtp or exchange server doesn;t use basic smtp commands it uses extended smtp commands called as ESMTP. for mail to work properly across firewall with rfc valid commands. set the inspect to ESMTP. i am sure this inspection is there by default.

regards

sebastan

suschoud Mon, 03/05/2007 - 10:38

"I am running version 7.2(2) and my exchange

server is win2k3 w/ service pack 1 behind the

firewall and I am having intermittent issue

with mail until I do "no fixup protcol smpt 25"

and the issue goes away. "

in 7.2.2,there's no command as fixup".

we have inspect commands in 7.x

please correct.

Correct Answer
oxys Wed, 03/07/2007 - 06:22

In 7.2.x (including the latest 7.2.2 interim releases) there are bugs related to SMTP/ESMTP inspection. PIX inspection engine drops connections if it finds a registered header name, as "Content-type", inside another header of any kind. This can happen if you use SpamAssassin and configure it to save reports inside e-mail header, or a remarkable case is Gmail which uses control headers containing other header names as keywords.

The problem is that RFCs do not forbid the use of a header name inside another header, but PIX/ASA Os 7.2.x incorrectly detects this behaviour as "malicious" because it sees a duplicate header. So it's the PIX that is wrong, not the messages. I opened a TAC case for this bug about one month ago.

The bug is now recognized as CSCsh33982, a level 2 bug. If you look in the Bug Toolkit you'll find the bug and you'll see that it is fixed in version 7.2(2)12 and 8.x. OS 7.2(2)12 is an interim release, but it is not public. Actually, today I installed it and I have found that the bug is not fully fixed: sometimes Gmail inserts two headers with the same keywords inside a message and the ASA/PIX still drops these messages. A new bug has been recognized: CSCsi01498.

So, at the moment, the only correct suggestion I can give you is to disable SMTP/EMSTP inspection if you use PIX/ASA OS 7.2.x. At least remove it for the traffic originated by or directed to your mail server if you don't want to loose messages.

Another note: serious modern e-mail servers allow you to configure security features for their SMTP service comparable or even better than those provided by PIX inspection. Even MS Exchange can be configured properly.

sebastan_bach Wed, 03/07/2007 - 06:28

hi man u have a great and a detailed understanding of the smtp protocol man not even ccie;s out here know the inner working of things like this. keep it up and keeps us updated on stuff like this.

just curious to know how did u find out this was the problem.

regards

sebastan

oxys Wed, 03/07/2007 - 06:41

I discovered the problem at the beginning of january because our e-mail servers could not receive a lot of messages. I understood that it was related to the upgrade of PIX OS from 7.1.x (yes, in 7.1.x ESMTP inspection works, but is less accurate than in 7.2.x) to 7.2.2.

It's not true that I have a deep understanding of SMTP protocol. I debugged PIX behaviour with the help of a Cisco engineer, I analyzed blocked messages, then I studied a lot of RFCs (but I understood only what I needed to understand the problem).

I hope that my message could help you. I hope that the TAC cases I have opened help Cisco fix this 7.2.x OS that I believe is too much buggy.

sebastan_bach Wed, 03/07/2007 - 06:43

hi buddy thanks a lot for ur reply.

i guess but the 7.2.2 code was just of bug fixes and suggested by cisco as the stable version.

regards

sebastan

Actions

This Discussion