Re: Configuring a Store-and-Forward backup qmail server
In article [EMAIL PROTECTED] Charles Roten [EMAIL PROTECTED] wrote: | I'm trying to set up a redundant "store-and-forward" mail server. | This box will reside much farther towards our network periphery | than the present Exchange server we are currently using. We will | set up a *secondary* MX record for it in DNS, so mail will only | go to it if the primary is unavailable. If we lose a critical | internal network node for, say, a day or two, the intent is that | this box will act as a "cache" until connectivity is restored, | then will forward the email it has been storing to the again- | available Exchange server. | I seem to have qmail running now .. thanks, again, to Greg Owen. | The problem now is how to set it up to *forward* mail to | *another* server. Paul Gregg's Single UID Mailbox HOWTO, at | http://www.tibus.net/pgregg/projects/qmail/single-uid-howto.html, | really does not seem to be what I am looking for, since it seems | to require a distinct entry in /var/qmail/users/assign for each | individual user. This is perfect for a situation where the | server is being used to manage POP-3 accounts, but the management | problems of this approach for a domain with, perhaps 300 to 400 | users, whose accounts are really managed at the Exchange server, | are unreasonable. | What I need is a configuration such that *all* emails coming into | the foo.com domain will be stored and, once the network link to | the primary server is back up, will be forwarded. There doesn't | seem to be any information at http://www.qmail.org/top.html about | how to do *that*. | Has anyone done something like this using qmail? Any pointers to | configuration data would be much appreciated. There are a couple of ways to do this. As another user suggested, store the emails in a POP box and have a method of kicking a maildirsmtp when your exchange comes online (usually a finger daemon will do this, I wrote my own fingerd in perl to handle this task). The other method, simpler, but more prone to problems if your exchange doesn't dialup for a period of time. Just put the domains in rcpthosts and either have a single all domains entry or define the specific domains which must be forwarded in the smtproutes file. This way, the qmail box becomes the main MX where all mail goes first. In smtproutes put: domain1.com:myexchangebox.mydom.com domain2.com:myexchangebox.mydom.com or simply: :myexchangebox.mydom.com If all domains from this qmail are going to be delivered to your exchange. Paul. -- | Paul Gregg | T: +44 (0) 28 90 424190 | | | Technical Director | F: +44 (0) 28 90 424709 | CLUB24 INTERNET | | The Internet Business Ltd | W: http://www.tibus.net | Free Access | | Holywood House, Innis Court | E: info @ tibus . net | www.club24.co.uk | | Holywood, Co Down, BT18 9HF | P: pgregg @ tibus . net | |
Re: Configuring a Store-and-Forward backup qmail server
On Mon, Aug 07, 2000 at 02:53:36PM +0100, [EMAIL PROTECTED] wrote: Just put the domains in rcpthosts and either have a single all domains entry or define the specific domains which must be forwarded in the smtproutes file. This way, the qmail box becomes the main MX where all mail goes first. In smtproutes put: domain1.com:myexchangebox.mydom.com domain2.com:myexchangebox.mydom.com No question about it: I would explicitly state which domains should be stored and forwarded in rcpthosts. The messages thus received will bounce after queuelifetime (man qmail-send). John
Re: Configuring a Store-and-Forward backup qmail server
Charles Roten [EMAIL PROTECTED] writes: What I need is a configuration such that *all* emails coming into the foo.com domain will be stored and, once the network link to the primary server is back up, will be forwarded. There doesn't seem to be any information at http://www.qmail.org/top.html about how to do *that*. Easy. You just need to feed all mail for your elected domain into a Maildir, and then use the serialmail tools when you finally want to deliver them to the end system. You'll need an appropriate entry in virtualdomains, the corresponding ~alias/.qmail- file, and some disk space to locate the Maildir on. Check out the manual page for maildir2smtp. It covers it all in there. James.
Re: Configuring a Store-and-Forward backup qmail server
James Raftery [EMAIL PROTECTED] writes: If one week is too short, put the number of seconds after which messages should bounce in control/queuelifetime. This is standard configuration for a backup MX. [I wibbled on about maildir2smtp] James's advice is, of course, far more appropriate if you're going to have the secondary MX there the whole time. You'll probably find that you'll receive mail there quite often, even when you believe your primary MX to have been available the whole time. Just watch out for bringing your exchange server back online after upgrades or crashes before you've configured it to accept your domain's email. I've seen huge amounts of bounces for mailing lists happen for cases like that. James.
Re: Configuring a Store-and-Forward backup qmail server
James R Grinter [EMAIL PROTECTED] writes on 4 August 2000 at 00:22:25 +0100 Charles Roten [EMAIL PROTECTED] writes: What I need is a configuration such that *all* emails coming into the foo.com domain will be stored and, once the network link to the primary server is back up, will be forwarded. There doesn't seem to be any information at http://www.qmail.org/top.html about how to do *that*. Easy. You just need to feed all mail for your elected domain into a Maildir, and then use the serialmail tools when you finally want to deliver them to the end system. You'll need an appropriate entry in virtualdomains, the corresponding ~alias/.qmail- file, and some disk space to locate the Maildir on. Check out the manual page for maildir2smtp. It covers it all in there. But do bear in mind that in "normal" operation a small percentage of mail will end up at the secondary MX, because of remote DNS and network outages and sheer perversity of the universe. I was originally going to have all the mail at the secondary held, and trigger delivery to the primary manually (so it wouldn't catch some intermediate state where the primary wasn't realy back up yet), but that approach won't work because mail will sit at the secondary without your noticing because the primary was never down. So I now have a process that does maildir2smtp every 10 minutes, and I hope I remember to stop it before I start working on recovering the primary. -- Photos: http://dd-b.lighthunters.net/ Minicon: http://www.mnstf.org/minicon Bookworms: http://ouroboros.demesne.com/ SF: http://www.dd-b.net/dd-b David Dyer-Bennet / Welcome to the future! / [EMAIL PROTECTED]