[TriLUG] backup email server

[Aaron S. Joyner]

Michael Hrivnak wrote:

>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!
>>
>>    
>>
Okay, the oldest question first.  It will retry the message based on the 
settings in main.cf for qmgr, check the qmgr man page for more details.  
The most important bits are:

>        minimal_backoff_time
>               Minimal  time in seconds between delivery attempts of a 
> deferred
>               message.
>
>               This parameter also limits the time an  unreachable  
> destination
>               is kept in the short-term, in-memory destination status 
> cache.
>
>        maximal_backoff_time
>               Maximal  time in seconds between delivery attempts of a 
> deferred
>               message.
>
>        maximal_queue_lifetime
>               Maximal time in days a message is queued before it is 
> sent  back
>               as undeliverable.
>
>        queue_run_delay
>               Time in seconds between deferred queue scans. Queue 
> scans do not
>               overlap.

Essentially, it starts with minimal_backoff_time and then retries less 
often at each attempt, until maximal_backoff_time is reached.  
minimal_backoff_time can't be less than queue_run_delay or the "wakeup" 
set for qmgr in master.cf, if I recall correctly.

Okay, the other question about Cox filtering mail.  Yes, your original 
idea would cause a very annoying mail loop.  You would send it to Cox, 
and they would send it back to you, as fast as possible.  Repeat ad 
nauseum until the Cox server admin disables your cable modem.  The much 
better solution is to setup your primary mail server to also receive 
mail on another high port (2525 would work fine) and use the transports 
file on the backup server to specify mail for that domain, to be 
delivered to that machine, on that port.  It would go something like this:
In main.cf: transport_maps = hash:/usr/local/etc/postfix/transport
in transport: hrivnak.org   smtp:[mail.hrivnak.org:2525]
Don't forget that transport is then going to be a hash, so you'll need 
to do this:
postmap ./transport
Note the ./ and don't leave it out.  You may substitute a full path if 
you prefer, but you must specify an actual path to the transport file, 
when using postmap.  "postmap transport" will not work as intended.

That ought to cover you pretty well for a backup mail server with 
postfix.  If you've got any more questions, just throw them out there.  :)

Aaron S. Joyner