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

2011-06-09 Thread Ben Kennedy
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:ves...@tana.it] 
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
courier-users@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

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



--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
___
courier-users mailing list
courier-users@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users


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

2011-06-09 Thread Sam Varshavchik

Ben Kennedy writes:


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?


Only a machine which has a domain configured as a local/hosted domain can  
know which address in the domain exists, or not.


One thing you can do is redefine a local domain. If you are example.com,  
rather than defining example.com as a local domain, define instead  
mailhost.example.com as a hosted domain, and install an alias


u...@example.com: u...@mailhost.example.com

Mail addressed to u...@example.com gets rewritten to be addressed to  
u...@mailhost.example.com, which would be a valid local mailbox. Nonexistent  
addres...@example.com get rejected because example.com is not a local  
domain. Adresses that exist get rewritten and delivered.


It should be a simple matter to write a script to dump your list of  
mailboxes, generate an alias entry for each valid mailbox, then run  
makealiases.


I believe that if you do that, you can install the same alias table on your  
secondary, and on the secondary put mailhost.example.com into  
esmtpacceptmailfor, so that mail for that domain gets accepted and queued.


If you've got mail queued up on the secondary, and want to make it a  
primary, you will need to stop courier, remove mailhost.example.com from  
esmtpacceptmailfor, and put it into hosteddomain, and start courier, and it  
should then deliver the queued up mail into local mailboxes.


You'll need to do some experimenting to verify this, but I'm fairly certain  
that it'll work.




pgpdoOa65UWPs.pgp
Description: PGP signature
--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev___
courier-users mailing list
courier-users@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users