[TriLUG] backup email server

[Michael Hrivnak]

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:<spamalicious at joyner.ws>
> > 250 Ok
> > rcpt to:<michael at hrivnak.org>
> > 450 <michael at hrivnak.org>: Recipient address rejected: User unknown in
> > local recipient table
> > mhrivnak at hrivnak.org
> > 502 Error: command not implemented
> > rcpt to:<mhrivnak at hrivnak.org>
> > 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.  :)