[TriLUG] seeking advice for a bullet-proof mail server

[Aaron S. Joyner]

Ryan Leathers wrote:

>Thanks for the follow-up question Matt.
>
>Certain systems will send mail to customers, and their responses to
>predetermined mailboxes will be parsed for further action or read by humans
>in some cases.  
>
>Another system which can only speak SMTP will send messages with distinct
>subject fields.  I will need to hand off incoming mail which matches an
>array of subject fields to a home-brew application which parses, talks to a
>database, fires off some jobs, and finally responds with another email.
>
>I know its ugly.  Its not my choice.  If I could do JMS I would.  SMTP is
>what I'm stuck with.
>This is obviously asynchronous, but I can only afford minutes - not hours of
>delay, which is why MX weighting is not a practical solution for me.
>Perhaps Aaron J's suggestion of putting all my eggs in one REALLY good
>basket is the right move, but I'm hoping for something better.  I know I
>could get the access behavior I want out of LVS, but I'm not sure how to get
>the data shared by both MTAs without a headache should hardware fail.  That
>is, unless I add a separate storage subsystem, which brings me back to my
>original post.    
>  
>
Does it matter what machine processes your request?  Is it possible to 
have different boxes responsible for fulfilling any particular request?  
Originally I wasn't reading closely enough to realize that you were 
automating a task other than the recieval of email - my bad there.  If 
your secondary server is configured to accept all mail locally for the 
automation domain as well, and forward any accounts in your regular 
domain to the normal mail server, then you can have that second host 
deliver mail properly *and* have it still do your "fancy task".  Note 
that if you're going to try to direct all mail based on subject, things 
are going to be really confusing.  I'd *strongly* suggest doing it based 
on destination address, if you have any control over it and a desire to 
keep your sanity.

If on the other hand your task can only be completed by one machine, for 
concurrency / storage / whatever reasons, or what-have-you, then you're 
back to my previous suggestion.

Aaron S. Joyner

PS - Also note that it's entirely possible to do not only fail over, but 
load balancing with MX trickery.  You can have more than one MX with the 
same priority, and traffic will be equally divided between them.  If 
your application needs to scale, and can be processed by multiple 
machines, that's the way to go about it.