A co worker of mine who used CheckPoint a few years ago said that back then
CheckPoint firewalls were more of a filter than store and forward for email.
However he says that he has not seen a recent version, and its almost
impossible to decode the truth behind the marketing hype as to what an
individual firewall does.
However, if CheckPoint is store and forward, then it should be the
responsibility of the firewall to run down all the MX records. TIS handed
all the email to sendmail running as an ordinary user in order to do the
delivery. To do otherwise would break email, as it does in this case.
On Monday, December 27, 1999 12:51 PM, Rick Murphy
[SMTP:[EMAIL PROTECTED]] wrote:
> At 09:36 AM 12/27/99 -0500, Ng, Kenneth (US) wrote:
> >The question I have in all this, why is it that Exchange does not retry
> >sending the email with the other MX entries? I understand that Exchange
> >sees a connection completed, and then a connection broken. At that point
> >why doesn't Exchange try one of the higher MX entries? I have a Sun
running
> >sendmail behind a Raptor firewall and it sends email out to the internet
> >just fine.
>
> The Firewall-1 SMTP proxy (oops.. security server) is similar to the FWTK
> smap/smapd pair. There's a daemon that receives the incoming mail which
> dumps the message into a spooling directory (just like smap). A separate
> despooling process processes the entries in the spool directory for
> delivery (like smapd).
>
> The problem with the SMTP security server is that it accepts the mail
using
> whatever the internal server sees as the first MX host. It records the
> destination IP address of that mail host, which the delivery daemon
> eventually uses to deliver the mail. The delivery agent doesn't use the
> envelope to figure out where to deliver the message; it just tries the
> address that the internal server originally tried.
>
> smapd doesn't have this problem because it tosses delivery responsibility
> to sendmail. The Firewall-1 security server is a simpler implementation
> (it's self-contained with no reliance on an external delivery agent) and
> thus arguably 'more secure' (whatever that means :-)
>
> As far as the internal mail server is concerned, the delivery was
> successful (they attempted to connect to the first MX for the domain; the
> connection was successful and the message accepted.) The server has no
idea
> that the message hasn't really been delivered yet.
>
> If you don't use the security server for outbound mail, there's no issue
> for most folks - there's typically a single internal system that accepts
> and routes incoming mail.
> -Rick
*****************************************************************************
The information in this email is confidential and may be legally privileged.
It is intended solely for the addressee. Access to this email by anyone else
is unauthorized.
If you are not the intended recipient, any disclosure, copying, distribution
or any action taken or omitted to be taken in reliance on it, is prohibited
and may be unlawful. When addressed to our clients any opinions or advice
contained in this email are subject to the terms and conditions expressed in
the governing KPMG client engagement letter.
*****************************************************************************
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
