Re: SOLUTION? how to hold mail in another machine temporarily
On Mon, 29 Jun 98 21:53:07 +0200, Carlos Carvalho wrote: Sure this is necessary, but I don't think it's enough. First, the temp machine must recognize all users, otherwise it'll bounce the message. Second, I'd like it to not only queue the mail but *dump it on the main one when it comes up*. If I just put the MX record, the secondary will hold the mail in IT'S /var/spool/mail, and users will not automatically get it. I found a solution: For every user, put a forward in /etc/aliases pointing directly to the main server (argh...). This works, but it's ugly. Is there a better way (using sendmail or other MTA)? Uhm, secondary MX machines should hold the mail for the main *machine* and not worry at all about the validity of users. Also, when the main machine comes back up it can force a dump from the secondary machines with the ETRN command. -- Steve C. Lamb | Opinions expressed by me are not my http://www.calweb.com/~morpheus| employer's. They hired me for my ICQ: 5107343 | skills and labor, not my opinions! ---+- -- Unsubscribe? mail -s unsubscribe [EMAIL PROTECTED] /dev/null
RE: SOLUTION? how to hold mail in another machine temporarily
Carlos Carvalho [EMAIL PROTECTED] writes: I asked some days ago here how to make another machine hold the mail while the main mail server is down. People told me to put another MX record in the dns to point to the temporary machine. Sure this is necessary, but I don't think it's enough. First, the temp machine must recognize all users, otherwise it'll bounce the message. No. The MX records determine who to send the mail to, not what the to address is. As long as any spam-filtering and anti-relaying software is configured that you are relaying mail to the primary machine, then it will take it all and wait until that system comes up to send it. Second, I'd like it to not only queue the mail but *dump it on the main one when it comes up*. If I just put the MX record, the secondary will hold the mail in IT'S /var/spool/mail, and users will not automatically get it. Well, instantly is going to be tough, you'll have to wait until the specific mail hits it's retry time as it polls the system until it's up. I know in experiences where my mail file was too big (didn't notice right away) and the SMTP server wasn't able to deliver to my account, when I fixed it, it was within 5 minutes before the floodgates started. -Jeff * | Jeff Schreiber | There is freedom and there is responsibility. | | aka - Spectre | You have obviously figured out the first | | [EMAIL PROTECTED] | but not the latter.| | | (Rob Schmunk - [EMAIL PROTECTED]) | * -- Unsubscribe? mail -s unsubscribe [EMAIL PROTECTED] /dev/null
Re: SOLUTION? how to hold mail in another machine temporarily
is the next most preferred contact. Host B knows that it is not the final destination (because of the MX record for host A) so it queues the mail in /var/spool/mqueue (if it's a linux box). Host B will attempt to deliver that mail for as long as the timeout period allows. That's correct. I just thought I'd add that you don't want to list host A in your sendmail.cw file (the list of domains for whom you want to accept mail). Since you said you have to put aliases on host B, it made me wonder if you were doing that. You don't want sendmail to accept the mail, per se, you just want it to relay it [eventually] to A. (Note also that the MX record for B should have a higher number (corresponding to a lower priority) than the MX record for A.) -- Pete Harlan [EMAIL PROTECTED] http://www.artselect.com -- Unsubscribe? mail -s unsubscribe [EMAIL PROTECTED] /dev/null
Re: SOLUTION? how to hold mail in another machine temporarily
Carlos qmail (www.qmail.org) has a feature called smtproutes that allows you to set up a machine with a higher MX to hold the mail in a local queue until the machine with the lower MX comes back up, then deliver to the main box. No additional users needed, and it works well. Cheers Si On Mon, 29 Jun 1998, Carlos Carvalho wrote: Hi folks, I asked some days ago here how to make another machine hold the mail while the main mail server is down. People told me to put another MX record in the dns to point to the temporary machine. Sure this is necessary, but I don't think it's enough. First, the temp machine must recognize all users, otherwise it'll bounce the message. Second, I'd like it to not only queue the mail but *dump it on the main one when it comes up*. If I just put the MX record, the secondary will hold the mail in IT'S /var/spool/mail, and users will not automatically get it. I found a solution: For every user, put a forward in /etc/aliases pointing directly to the main server (argh...). This works, but it's ugly. Is there a better way (using sendmail or other MTA)? Carlos -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SOLUTION? how to hold mail in another machine temporarily
On Mon, 29 Jun 1998, Carlos Carvalho wrote: : Hi folks, : : I asked some days ago here how to make another machine hold the mail : while the main mail server is down. People told me to put another MX : record in the dns to point to the temporary machine. : : Sure this is necessary, but I don't think it's enough. First, the temp : machine must recognize all users, otherwise it'll bounce the message. : Second, I'd like it to not only queue the mail but *dump it on the : main one when it comes up*. If I just put the MX record, the secondary : will hold the mail in IT'S /var/spool/mail, and users will not : automatically get it. Huh? MX records are Mail eXchange records - this is what they were designed for. Let's say host A has an MX preference of 10, and host B has a preference of 20. As long as a machine can deliver mail to host A, host B will never see it - the mail will be delivered directly to host A, and the MTA there will deliver the mail locally (or do whatever is appropriate). Now, let's imagine that host A goes down - it is unreachable from the Internet. All mail destined for host A will now be delivered to host B. Both MX records still exist, but since host A cannot be reached host B is the next most preferred contact. Host B knows that it is not the final destination (because of the MX record for host A) so it queues the mail in /var/spool/mqueue (if it's a linux box). Host B will attempt to deliver that mail for as long as the timeout period allows. : I found a solution: For every user, put a forward in /etc/aliases : pointing directly to the main server (argh...). This works, but it's : ugly. Is there a better way (using sendmail or other MTA)? See above :) -- Nathan Norman MidcoNet - 410 South Phillips Avenue - Sioux Falls, SD 57104 mailto://[EMAIL PROTECTED] http://www.midco.net finger [EMAIL PROTECTED] for PGP Key: (0xA33B86E9) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
