Interop problem with SMTP STARTTLS and Cisco PIX firewall

A major interoperability problem has shown up which results from an
egregious firewall implementation interacting with an insufficiently
flexible STARTTLS implementation.

The clear standards violator here is the Cisco PIX firewall -- there is a
case where it advertises STARTTLS, but totally violates RFC 2487.  The
problem is it passes the EHLO response from the backend host unaltered,
but the firewall responds with a success response to any unknown command
(a clear violation of RFC 821). 

Exchange 5.5 service pack 2 always advertises STARTTLS (although it
generates a failure response to the STARTTLS command if no cert is
configured).  This is technically standards compliant, but wasteful in the
common case and dangerously inflexable in this case.

Thus a Cisco PIX firewall front-ending for Exchange 5.5 SP2 will fail to
interoperate with any standards compliant TLS-enabled SMTP client. 

ATTENTION SMTP STARTTLS IMPLEMENTERS:

Make sure there is at least a mode where STARTTLS is not advertised.  A
quality implementation will only advertise STARTTLS if a valid server cert
is correctly configured. 

ATTENTION USERS OF CISCO PIX + EXCHANGE 5.5:

Don't install Exchange SP 2 until your broken firewall is replaced with a
functional one.

My personal opinion: If you must have an application-level firewall, I
recommend getting one from a vendor specializing in that application; buy
a filtering proxy for HTTP, a filtering proxy for LDAP, and an SMTP server
with firewall mode for email, etc.  Generic firewall products have
repeatedly caused interoperability and security problems due to inadequate
understanding of application protocols.


Feel free to forward this message to appropriate people who can get things
fixed.

		- Chris