Re: [courier-users] Backup MX, was Courier::Filter rejecting over-zealously

[Ben K. <be...@zy...>]

Hey folks,

Some of you may recall this discussion from last fall.  I've got a
problem, one that I guess my servers have exhibited for years, and I
want to fix it.

I have two machines, which I'll call "primary" and "secondary".  They
are both MX for a number of domains; primary has a lower priority number
(i.e. is a first choice for delivery), and holds the canonical backing
store (maildirs, POP3/IMAP service, etc).  Secondary is designed to also
accept mail for these domains, and shunt any it happens to receive (by
virtue of esmtproutes) to primary.  Both have mailbox configuration
provided by authmysql from a local replicated MySQL database.

In case primary goes down, secondary will continue to queue mail and, at
my option, may be quickly switched into "primary behvaiour" (to deliver
locally and provide POP3/IMAP service) in the event that the original
primary cannot be brought online in a timely fashion.

I have used this pattern for several years now, with general success.

The gaping hole, of course, is that the secondary will accept any mail
for any mailbox on any of the domains.  For domains with "alias@..."
style catch-alls, this is fine.  For the rest, it induces the primary
into spewing out backscatter for any undliverable addresses.

As I said, both machines share the mailbox config, and therefore have
the capability of knowing what is a legitimate address and what isn't. 
But on the secondary, which has empty hosteddomains and esmtproutes
pointing to the primary, it never bothers to do an account lookup (it
only looks at the domain).

How do I fix this?

thanks,

-ben


Malcolm Weir wrote at 11:53 AM (-0700) on 9/24/10:

>-----Original Message-----
>>From: Alessandro Vesely [mailto:ve...@ta...] 
>>Sent: Friday, September 24, 2010 2:40 AM
>
>>> In my experience, enterprises of size actually operate dedicated boundary
>>> servers as their MX platforms, and final delivery is handled by an
>entirely
>>> different set of servers often totally invisible to the outside user.
>
>>While that's correct, those invisible servers are not _primary_ MXes 
>>on the public Internet.  So, it is still unanswered why large 
>>enterprises may want to operate _secondary_ MXes, i.e. MXes with a 
>>higher preference number.
>
>Ummm... the "invisible servers" are not actually any kind of MX on the
>public
>Internet, primary or otherwise.
>
>There is a certain amount of confusion in this area because a lot of the
>mindset
>is structured around the notion that the "primary MX" is final recipient
>(the
>MDA), and other MX nodes end up relaying traffic to that "primary".
>
>But if you use a purpose designed "boundary server" whose sole job is
>scanning
>and filtering, then forwarding the scanned mail to distinct delivery nodes,
>you
>may well choose to implement multiple such systems attached to different
>network
>providers and/or points-of-presence.  In this model, the MX is just another
>MTA,
>quite distinct from the MDA and MSA.
>
>For example: suppose you have campuses in Los Angeles and New York. Each
>campus
>has its own connection to the Internet, but also a private network between
>the
>two. Even if you want the bulk of outside traffic, and all mail, to go to
>LA, it
>may make sense to have an MX based in NY with a lower priority that routes
>its
>traffic to LA over the private network. That way a service outage on the LA
>campus would not bring down all external mail acceptance.
>
>I don't think we're in disagreement with anything, here, other than perhaps
>the
>issue created by the fact that "MX server" has been conflated with "delivery
>server", a fact that should surprise no-one who's seen the separation, over
>time,
>of the MTA, MDA and MSA parts of the system.
>
>Malc.
>
>
>
>
>------------------------------------
------------------------------------------
>Start uncovering the many advantages of virtual appliances
>and start using them to simplify application deployment and
>accelerate your shift to cloud computing.
>http://p.sf.net/sfu/novell-sfdev2dev
>_______________________________________________
>courier-users mailing list
>cou...@li...
>Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

-- 
Ben Kennedy (chief magician)
zygoat creative technical services
http://www.zygoat.ca