[TriLUG] backup email server

[Michael Hrivnak]

And one more.  I've found my backup server at the mercy of an ISP that filters 
outbound port 25 (Cox), so I'm forced to use relayhost = their.smtp.server.  
Presumably, that puts me at the mercy of their server configuration 
concerning how long it will rety the delivery of mail to my primary machine.

What I'm concerned about is a loop.

1. Primary server is down, so email is send to backup.
2. Backup server relays through the cox server to primary
3. Primary is still down, and so the Cox server goes down the mx list and 
delivers to the backup server.
4. Goto step 2.

Is this what would actually happen?  How do you all suggest I get around this?  
Just for kicks, what if the primary host were also listening on another port, 
say 2525 (can I do that?).  The backup server is set so that relayhost = 
hrivnak.org:2525.  If the relayhost is the same as the final destination, how 
will it behave?  If hrivnak.org is down, would it still put it into the queue 
and continue to attempt delivery until the relayhost came back up?

Thanks a ton,

Michael

On Monday 21 June 2004 12:14 am, Michael Hrivnak wrote:
> 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.  :)