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 -- 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
