One more question: If my primary server is down, how often will the backup server retry? I took my primary server down just long enough to send a test message through the backup server, and I'm wondering when I should be expecting it!
I've manually tested the setup, and it works beautifully relaying email as long as both servers are up. The only quirk is that I had to change it to use all interfaces instead of the default "localhost". Thanks again, Michael On Sunday 20 June 2004 10:47 am, Aaron S. Joyner wrote: > Tanner Lovelace wrote: > > Michael Hrivnak said the following on 6/20/04 12:00 AM: > >> mydomain = hrivnak.org > >> mydestination = $myhostname, localhost.$mydomain, localhost > >> relay_domains = $mydestination hrivnak.org > >> delay_warning_time = 24 > >> > >> The rest are defaults. I think this will make the machine relay mail > >> to hrivnak.org. Am I correct? > > > > Now, the other wrinkle here is that if the second mail server > > for some reason thinks its the final destination for hrivnak.org > > it will try to deliver the items locally. I've only ever used > > backup mail servers in other domains, so I'm not sure what > > switches to use to make sure it doesn't keep any mail locally > > that should be sent on. Perhaps someone else can speak to that? > > > > Cheers, > > Tanner > > To build on what Tanner has already said, you need Postfix *not* to see > hrivnak.org as a local destination. That's controlled in Postfix by > mydestination=<blah>. In your above configuration you have setup > mydestination, and it appears to be quite acceptable. As long as the > hostname of the machine is not hvirnak.org (doubtful) then you should be > in good shape. There are a few other things to keep in mind, though. > Does this machine to spam checking, or username validation? Since > hrivnak.org isn't going to be a very heavily traveled domain, you're not > likely to attract the attention of spammers sufficiently to make this a > problem, but... be aware that with a secondary mail server that accepts > mail for all usernames, it's entirely possible that I can fill the queue > to ridiculous proportions simply by sending a lot of bogus mail, > attempting to find out what's a valid address and what isn't. Probably > not much of a concern, but if it is look into the verify and > relay_recipient_maps features. > > You also asked about a few other things: > >The mail sits in Que I guess waiting > >to be relayed. How often does postfix attempt to relay it? Do I have > >control over this? Does it ever give up? Where exactly does the email > > sit? > > If the message passes the relay checks (which you've allowed above with > relay_domains), then it is accepted into Postfix just like a regular > message, and abides by all of the regular message-processing routines. > The message then gets dropped into /var/spool/postfix/active and > delivery is attempted (it actually makes a short stop through > postfix/incoming before it's accepted for relaying). If delivery > succeeds, well, it's gone. But if you're primary mail server isn't up > for what ever reason, it gets dropped into the deferred queue. > /var/spool/postfix/deferred contains the actual message itself, and > /var/spool/postfix/defer contains the error message. Under each of > these directories is a set of subdirectories (active, defer, deffered, > etc) labeled [0-9A-F], which corresponds to the first character of the > message ID. In a small mail system, you can do an ls -l defer*/*/* and > see all of the messages that way. On a larger mail system that > segregation helps keep the directory sizes manageable, and doing a > command like that can be a bit... output intensive. :) We often do a > simple find command piped through wc -l, as quick way to find the number > of messages in each of the queues. > > So does it ever give up? :) Yes, it does. As controlled by > maximal_queue_lifetime in main.cf. You also already have found > delay_warning_time, which will determine when the sender is notified > that there was a delivery problem with the message. You set it to 24h, > which might be a bit high. The default is 4h, and is fairly > respectable. Imagine that if someone sends you a message, they will > presume you've gotten it, unless they are notified otherwise. 24 hours > might be a bit long for them to be under that incorrect assumption, but > that is entirely your choice. One of the nice benefits of running your > own mail system. :) > > Hopefully that has answered all of your questions. Before I close this > out I'll throw out one thing - test it manually. It's rather easy to > generate a test message by hand, to a mail server. Connect from > somewhere other than local host, so you know relaying is working, and > send it a message by hand. All you need to do it telnet to port 25, and > > the session will go something like this: > > Trying 24.167.140.251... > > Connected to mail.hrivnak.org. > > Escape character is '^]'. > > 220 hrivnak.org ESMTP Postfix > > ehlo joyner.ws > > 250-hrivnak.org > > 250-PIPELINING > > 250-SIZE 10240000 > > 250-VRFY > > 250-ETRN > > 250-STARTTLS > > 250 8BITMIME > > mail from:<[EMAIL PROTECTED]> > > 250 Ok > > rcpt to:<[EMAIL PROTECTED]> > > 450 <[EMAIL PROTECTED]>: Recipient address rejected: User unknown in > > local recipient table > > [EMAIL PROTECTED] > > 502 Error: command not implemented > > rcpt to:<[EMAIL PROTECTED]> > > 250 Ok > > data > > 354 End data with <CR><LF>.<CR><LF> > > Subject: Test Message number 1 > > > > Here it is! > > Aaron S. Joyner > > > > . > > 250 Ok: queued as 90CDE1ECA0A > > quit > > 221 Bye > > Connection closed by foreign host. > > Everything that doesn't start with a number is a command I entered. > Connect up to your secondary mail server, chat a message out to it, and > see if it shows up in your inbox. Then, once you're sure it works > correctly, you can setup the DNS MX records to actually put it in "harms > way" of mail, so to speak. :) > > Best of luck with all of this, > Aaron S. Joyner > > PS - Intrex does backup mail hosting for those interested in a > commercially provided solution. :) -- TriLUG mailing list : http://www.trilug.org/mailman/listinfo/trilug TriLUG Organizational FAQ : http://trilug.org/faq/ TriLUG Member Services FAQ : http://members.trilug.org/services_faq/ TriLUG PGP Keyring : http://trilug.org/~chrish/trilug.asc
