Thanks, in no particular order, go to:
Jonathon W. Ross [firstname.lastname@example.org]
Karl Vogel [email@example.com]
Hendrik Visage [firstname.lastname@example.org]
Kevin Colagio [email@example.com]
Dan Brown [firstname.lastname@example.org]
a) replace inetd with xinetd - A good idea. Had a very quick look at xinetd
and it seems to be decent. Will look at it closer as it's always nice to
have a bit more control over things.
b) replace inetd with tcpserver which does have this functionality
(http://cr.yp.to/ucspi-tcp.html) - As per xinetd.
c) replacing smap with qmail - If I was going to do this I'd have needed to
build a new machine and put it in the DMZ, I'd rather use sendmail in this
case but that's personal preference, and to my mind, more a religious debate
d) using the inetd protection that controls the inetd connection rate. -
This isn't really what I was after, more interested in total number of smtp
connections as opposed to x number of smtp connections per second.
e) setup a "DMZ" where there were a couple of Sendmail servers, where all of
the mail was mx'ed through. These in turn, fed the fireall with smap via
hardwired Sendmail configs. - This is pretty close to what we did.
And the solution that worked for me:
I added an MX that lets our upstream act as a secondary. Mail that was
bouncing from our server is being sent to the secondary and sent to us at a
later time. The biggest problem was messages timing out and then retrying,
thereby further congesting a slow, congested link.
Thanks again to all who answered. Goes to show that there's more than one
way to skin a cat (NB: I do not condone the skinning of cats or any other
Western Australia Police Service
E-mail: email@example.com E-mail: firstname.lastname@example.org
Fax: +61 8 9222 1698 Fax: +61 8 9219
Phone: +61 8 9222 1117 Phone: 0410 641 574
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:14:09 CDT