[TriLUG] backup email server

[Michael Hrivnak]

Dear all,

It all finally works, thanks in large part to Aaron Joyner's help.  Just for 
completeness, here's how I handled this last issue of the ports.

Rather than bother postfix with listening on another port (and bother myself 
with learning how to make it do so), I did this on my primary machine:

iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 2525 -j REDIRECT / 
--to-ports 25

I had to do  a "modprobe ipt_REDIRECT" first however, since my kernel doesn't 
like to auto-load modules.

Michael

On Monday 21 June 2004 07:27 am, Aaron S. Joyner wrote:
> 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