I think that SP-3 had a problem when it came to dealing with multiple MX
records (exchange and especially Micro-$ofts DNS service), and when SP-4 was
applied the performance improved. I think that the major problem is the DNS
server, if it isn't relaying additional MX's to exchange, then exchange can't
try them.
"Ng, Kenneth (US)" <[EMAIL PROTECTED]> 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.
>
> On Sunday, December 26, 1999 8:43 PM, Chris Brenton
> [SMTP:[EMAIL PROTECTED]] wrote:
> > Jerald Josephs wrote:
> > >
> > > Inquire whether he is using the SMTP Security Server
> > > on the FireWall-1 platform to check outbound mail for
> > > Content Security.
> >
> > My guess would be "yes". At the very least, they are using the security
> > server as an SMTP relay.
> >
> > > The FW-1 SMTP Security Server is not able to do
> > > MX lookups, so if the first mail relay is not responding,
> > > the email will not go out.
> >
> > Quite true. The whole process goes something like this:
> > The internal mail server has an outbound SMTP message to deliver
> > The internal mail server performs an MX record lookup
> > The internal mail system attempts to deliver the message to the lowest
> > MX value
> > FW-1 SMTP security server grabs the message
> > The IP address of the final destination is recorded
> > The message is processed against any filtering rules
> > Delivery is attempted to the IP address of the final destination
> >
> > So its easy to see why this whole thing falls apart. If the lowest MX
> > record value is not on-line and using the IP address recorded by the
> > SMTP security server, the message will never get delivered. I've see 1+
> > year old messages still sitting in queue.
> >
> > This error can be cleared my manually editing the file and replacing the
> > destination IP address with that of a higher preference MX system. This
> > will allow you to clean out the queue but does not "fix" the problem as
> > the next message sent to the same domain will die as well.
> >
> > > The solution at his site would to explicitly define a SMTP service
> > > rule before all other SMTP resource rule that would allow his
> > > Exchange Server to send out SMTP to any destination. This would
> > > prevent the SMTP Security Server from attempting to resolve an MX
> > > record.
> >
> > Agreed. Use the SMTP security server to process inbound messages while
> > allowing the internal mail system to transmit outbound directly. The
> > other option is a separate box (like a Linux system) which acts as a
> > dedicated mail relay.
> >
> > > I am sure the Exchange Server can do multiple MX lookups.
> >
> > Without breaking a sweat. ;)
> >
> > Cheers,
> > Chris
> > --
> > **************************************
> > [EMAIL PROTECTED]
> >
> > * Multiprotocol Network Design & Troubleshooting
> > http://www.amazon.com/exec/obidos/ASIN/0782120822/geekspeaknet
> > * Mastering Network Security
> > http://www.amazon.com/exec/obidos/ASIN/0782123430/geekspeaknet
> > -
> > [To unsubscribe, send mail to [EMAIL PROTECTED] with
> > "unsubscribe firewalls" in the body of the message.]
> *****************************************************************************
> 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.]
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
