Jennifer Tippens <[EMAIL PROTECTED]> wrote:
>
> So mail comes to our firewall, no problem.
Big problem, if you were running sendmail. You don't want anyone
owning your firewall!
A better idea, if you have the resources, is to create a DMZ, put your
mail server in it (running qmail), and pass packets for firewall:25
through to mailserver:25 with your filtering/forwarding rules.
Since your outside firewall should consider the DMZ untrusted, losing
your mail server to crackers doesn't directly endanger your entire
network.
> What we would like to do is have all mail forwarded through the firewall
> to an internal machine. I understand that I could do this with .forward
> or fastforward...
A better way is my suggestion above: don't forward messages; forward
at the connection level.
> but I thought that if I did that and the internal mail server went
> down for any weird reason that the mail would bounce.
Only if it goes down and stays down for several days. MTA's know about
temporary failure, and they try again.
> What I would like is for the mail to spool up on the firewall if the
> internal server is down.
It already spools up on the MTA machines; why bring the resource cost
upon yourself? Hopefully, your internal mail server is approximately
as reliable as your firewall, of course. It's not in a public cluster,
being used to play freecell, right?
> What is the best way to handle this? We have a lot of users.
Best or not, my suggestion dramatically saves resources. It likely
enhances security, as well. Your firewall shouldn't even have normal
users (except one for you). Qmail is invulnerable, but moving your
mail queue inside reduces exposure and avoids duplication of queues,
and the need for a big disk on your firewall box.
HTH,
Len.
--
Are they aware that the Internet doesn't _have_ a reliable receipt
mechanism? Netscape is advertising a feature that it can't deliver.
-- Dan Bernstein
