Greg,
I have encountered this problem before with a couple of different 'proxy'
based firewalls.
I discussed the problem with the firewall developers, who appreciated my
dilemma, but pointed out that it is not a fault, but a characteristic of a
proxy based firewall. The only solution on the firewall side of things, was
to install a SMTP server on the firewall to act as a relay, which in
depending on the circumstances may not be suitable.
I then discussed the problem with a couple of different developers who have
written SMTP implementations, and the general consensus was that although
the RFC guidelines are quite vague, Dan has put a bit too much thought in to
the MTA, and shouldn't differentiate between a connection timeout or drop,
and just step to the next MX record.
Don't get me wrong, I love Qmail, but this is just one thing that has
frustrated me.
I was provided some information on how to modify the Qmail code to address
this issue, but being a non-programmer, I decided not to go butchering the
code. Here's the details...
>
> modify the routine smtp() to close the smtpfd socket and return if the
> connection is dropped?
>
> if (smtpcode() != 220) { close(&smtpto); return; };
>
> near the top should probably do the trick.
>
> notes... because of the way your firewall works you can't rely on qmail's
> tcpto mechanism to prevent excessive connections to the firewall if its
> demarc/internet connection fails -- qmail can't tell if it;s a problem
> with the firewall or the remote end of the smtp connection. otherwise I'd
> have re-ordered the code around the call to smtp() not to mark the mta as
> 'up'.
Anyway, that's my 2c worth, I hope I haven't offended anyone (Dan
especially).
Karl Lellman
Systems Consultant
Extranet Technologies Limited
Level 3, 60 Cook Street, Auckland, New Zealand
P.O. Box 7726, Wellesley Street, Auckland, New Zealand
Phone +64 9 3771122, Fax +64 9 3771109, Mobile +64 21 771188
e-mail: [EMAIL PROTECTED]
-----Original Message-----
From: Greg Owen [mailto:[EMAIL PROTECTED]]
Sent: Thursday, 16 September 1999 08:31
To: 'Qmail List'
Subject: RE: When will qmail back off to the next MX?
> But it seems that qmail isn't backing off, probably
> because it gets a connect rather than getting a refusal.
>
> Should qmail be backing off? Is accepting+dropping connections
> documentably wrong, that I should complain to them about it?
> What's the deal?
Part of the problem cleared up - the accept+drop behavior appears to
be what you get when you turn off the SMTP proxy capabilities of Raptor
firewall. I'm guessing that the "connect" is accepted by the firewall,
which then drops it when it figures out the actual target isn't available.
Are there gauntlet/raptor users out there who are familiar with
qmail through the firewall? We had our ISP turn off the SMTP proxy
capabilities because they were making it hard for me to figure out why some
mail wasn't delivering well, so maybe it does the same with or without SMTP
proxy enabled...
--
gowen -- Greg Owen -- [EMAIL PROTECTED]
