Re: RFC 1891 and firewalls that break it... (fwd)

[Matti Aarnio <matti.aarnio@tele.fi>]

For your information: About weird ORCPT errors...
	/Matti Aarnio <mea@nic.funet.fi>

PS: "notifications" was name of the IETF working-group that defined
    SMTP DSN facility.

----- Forwarded message from Ned Freed -----
Date:	Wed, 25 Feb 1998 01:18:47 -0800 (PST)
From:	Ned Freed <Ned.Freed@innosoft.com>
Subject: Re: RFC 1891 and firewalls that break it...
To:	Matti Aarnio <matti.aarnio@tele.fi>
Cc:	notifications@CS.UTK.EDU

> 	Back when the DSN mechanisms were constructed, we never
> 	thought that somebody would make invisible devices that
> 	break DSN's ORCPT passing -- and perhaps something else
> 	too.

> 	An example to try:

> 	$ telnet magic-mail.adaptec.com smtp
> 	...
> 	EHLO something
> 	...			<<-- note DSN facility report
> 	MAIL FROM:<Yourself@Your.Domain>	<<-- use your own id!
> 	...			<<-- successfull ?
> 	RCPT TO:<nobody@adaptec.com> ORCPT=rfc822;nobody@adaptec.com
> 	501 Syntax error on ORCPT parameter ...
> 	RCPT TO:<nobody@adaptec.com>
> 	250 Address ok		(or "no such user", but no "Syntax error"!)


> 	Other servers with similar behaviour:
>                 smtp.oras.com
>                 mail.sacbee.com

> 	That Adaptec's server is sendmail-8.8.8 per its "220"
> 	banner text.   I won't accept suggestions that my sending
> 	MTA fails on general principle as this Adaptec server is
> 	the only SM-8.8.8 that fails (so far), while there must
> 	be hundreds of other SM-8.8.8's that don't fail with
> 	similar feed.

> 	Also I have seen M$ Exchange 5.5 to fail, and not to fail.
> 	The one that don't fail is in same LAN as I am, failing
> 	one is somewhere beyond the network.

> 	So far my suspicion is that there is some "smart" firewall
> 	in front of these DSN speaking systems, but the damn thing
> 	touches on the TCP-streams flowing thru :-/

> 	Does anybody have any idea what product there is ?

My guess would be the Cisco PIX firewall product. We have seen at least two
separate incidents at two different sites where this product was known to be in
use and had problems with its SMTP proxy service. In addition to the sort of
thing you've reported here, it seems that it likes to send NOOP commands to the
destination server sometimes. Unfortunately, it sometimes does this in the
midst of message data :-(

> 	Has anybody ever met the thing ?
> 	(I have heard suggestions that it could be "cisco PIX firewall",
> 	 but I have no positive confirmation on that.)

I cannot confirm that this is the product you are dealing with, but I can
confirm that the PIX firewall is known to have problems of this sort.

> 	More importantly, who makes the box, and how this bug can
> 	be fixed and fix deployed before it makes the DSN facility
> 	alltogether unusable in the Internet at large ?

> 	<news flash> I called ORAS.COM manager (it is a Finnish company)
> 		     and he told me the problem is definitely "cisco PIX".

I'm not surprised.

> 	For the DSN handling the problem is, such transparent stream-
> 	munging firewalls are invisible every time.  There is no way
> 	to detect them before the remote system yields "501 xxxx" code.
> 	(And really I would not care to create new kludges for
> 	 retrying address feed without DSN in that case...)

I agree that this sort of thing is a problem -- a major one, in fact. This
is why I've written an Internet Draft to try and bring these things under
the auspices of existing protocol standards. All too often broken behavior
is condoned in the interests of security. We need to take a firm stance that
this sort of thing is not acceptable.

				Ned

----- End of forwarded message from Ned Freed -----