advice needed, strange mail arrangement desired

Tue Oct 24 21:17:14 UTC 2006

On Tue, 2006-10-24 at 13:56 -0400, Jeff Kinz wrote:
> On Tue, Oct 24, 2006 at 10:32:24AM -0700, Rick Stevens wrote:
> 
> > On Tue, 2006-10-24 at 12:37 -0400, Jeff Kinz wrote:
> > > hi all, I need some advice
> > > 
> > > I am re-architecting my home network to use a more environmental server.
> > > The new server uses a lot less power, has a built-in battery power
> > > supply, and a much slower hard drive.  That's right, it's an old laptop!
> > > 
> > > this "server" will be acting as an IP tables based firewall
> > > and an SMTP server.  I will be using a much more powerful desktop
> > > machine as my personal workstation.
> > > 
> > > I'm trying to arrange my mail delivery system so that the server can
> > > receive all the incoming mail but eventually deliberate to my desktop
> > > machine, where I will be running procmail and mutt.  My MTA is sendmail
> > > on the server, and on the desktop machine as well, since I know how to
> > > integrate procmail and mutt with it.
> > > 
> > > Here's a simplified schematic: (needs a fixed font for proper display)
> > > 
> > > 
> > > Cable Modem-->Server(laptop)-->hub-----|--->desktop
> > >                                        |--->N other machines
> > > 
> > > 
> > > so here is my question:
> > > 
> > > The desktop machine will only be running about eight hours a day, maybe
> > > 14.  So there will be periods of time when mail will becoming into the
> > > server and its final destination, the desktop will not be available.
> > > 
> > > Can anyone give me a recommendation about how to configure sendmail on
> > > the server so that it won't throw any of the mail that needs to get to
> > > the desktop away, and so that as soon as the desktop comes up each
> > > morning, or maybe after a three-day weekend, it will instantly, or
> > > nearly instantly, or at least very soon thereafter deliver that mail to
> > > the desktop?
> > 
> > In this instance the laptop is called a "spooling" mail server and
> > it's not uncommon.  However, it's usually used as the secondary MX
> > entry for a domain.  If the primary MX machine goes down, mail goes to
> > the secondary machine.  As soon as the primary comes back up, the
> > secondary shoots all the mail it queued for the domain to it.  This
> > requires two MX entries in DNS for the domain, with the primary set to
> > a low metric value and the secondary to a high metric, e.g.
> > 
> > 	IN   MX   10   primary.fred.com
> > 	IN   MX  100   secondary.service.com
> 
> Hi Rick! :-)

Hi, yourself!

> Both machines are at the same public IP with the server/firewall getting
> all the port 25 traffic.  The desktop machine is not visible from the
> internet.  Are you saying I should forward all port 25 traffic to the
> desktop during its working hours and then keep port 25 at the server
> whenever the desktop is down? Then have the server sendmail just keep
> retrying delivery until the desktop comes back up? That may actually be 
> doable....   Needs a heartbeat and failover script.

That sure would work.  Another thing is to simply have the server set
up as the MX for your domain all the time and add appropriate entries
in the user database to forward the mail directly to your desktop when
it comes up.  So, the mail sent to "fred at bedrock.com" comes to the
laptop.  The laptop transforms it to "fred at desktop.bedrock.com" and
_tries_ to forward it to "desktop".  It's down, so it keeps retrying
until it comes up.  And Bob's your uncle!  That's what a spooler is
for.

> The failover script would modify the port forwarding on iptables
> script...... hmmm
> 
> Perversely - I don't want to loadkill the server while the desktop
> isn't running and at the same time I want the server to be instantly
> responsive when the desktop is up.  Due to the slow hard drive in the
> server I want to move as much processing and small email files off the
> server as possible. btw, the server is running Centos 4.4 (RHEL 4.0
> clone)

Do you get tons of mail while the desktop is off?  I ask because the
actual TCP transfer of mail is reasonably slow and the performance of
the disk probably wouldn't be an issue--you'd be more I/O bound from
the network side rather than the storage side.  The size of the disk may
be a problem if you do get lots of mail however.

> > secondary.service.com must be configured to relay fred.com mail.  Well
> > designed spool machines will also set up a separate queue for relay
> > mail, perhaps with different expiration times.
> > 
> > Now, if primary.fred.com goes down, the MX records will cause the mail
> > to go to secondary.service.com.  secondary will try to relay to
> > primary.fred.com, which will fail.  It will continue to try to relay
> > until it succeeds or the bounce time for the messages expires.
> >   
> > This probably won't work for you, and it's probably overkill.  If you
> > intend to have your desktop pick up the mail from the laptop via
> > fetchmail, there's no big deal.  Here's what I'd do:
> > 
> 
> Thanks , but I REALLY don't want fetchmail in the loop,
> especially when the desktop is up and running.  And especially be cause it
> modifies the mail headers that I want to use procmail on.
> Also - when working with a customer having to wait 5 extra
> minutes to get an email would be disruptive during teleconferencing.
> (I much prefer select to poll.. :-) )

Unless you have the kernel bug that causes select() calls to not return
if you hit the "magic window" around midnight GMT.  :-)  I don't think
Linux ever had that bug, but BSD and Solaris did for a long time!

> > 1. Put an entry in /etc/anacrontab to run fetchmail as the user you
> > want:
> > 
> > 	1  5  grabmail    su username fetchmail
> > 
> > This ensures that fetchmail runs at least once a day, and if the machine
> > happened to be off, it'll run 5 minutes after it's rebooted.
> > 
> > 2. Add a standard fetchmail to the user's standard crontab:
> > 
> > 	crontab -e username
> > 	5 * * * * fetchmail >/dev/null 2>&1
> > 
> > to run fetchmail every 5 minutes.
> > 
> > Anyway, you get the idea.
> > 
> 
> Indeed i do : 
> poll mail.comcast.net protocol POP3: user foob, with password norkadl7, is jkinz here; options antispam 501 451
> is how I get the email that goes to my isp, but 99.999 % comes 
> directly to kinz.org which is highly preferred.

Yup.

----------------------------------------------------------------------
- Rick Stevens, Senior Systems Engineer     rstevens at vitalstream.com -
- VitalStream, Inc.                       http://www.vitalstream.com -
-                                                                    -
-            The gene pool could use a little chlorine.              -
----------------------------------------------------------------------