In pursuit of the perfect mail system I think it's
important to define what qualities are important.
In services networks like mail, web, DNS, and friends
speed and reliability are the two most important
factors and as long as you are just providing email
to end users as a service, be it at an ISP or at
an office, reliability is the number one criteria.
This is not to say speed isn't important, but you're
end users will just get used to whatever speed it
runs at, and quite frankly, not only does most
hardware sit idle most of the time in most topologies,
the email doesn't need to fly at real time speeds.
If it took an extra minute to get that picture of
Grandma downloaded, it may be a little annoying at
worst, but if for some reason that picture of Grandma
wasn't available... That's a major upset.
This will of course, vary from installation to
installation. Also, please keep in mind that you
solicited opinions, and that I think your setup solves
your installations needs. Using an LDAP centric database
as the "right" way to do things, is something that I am
not convinced of.
In response to your example:
> Consider for a moment a setup which involves
> more than one machine running cyrus-imapd, would
> you have to keep a distinct alias table on each
> machine to resolve domain aliases? Compare this
> to a centralised approach using a single config
> located in an LDAP directory.
This could just as easily be solved by a script which
genrates the alias files out of a central configuration
database, which might be ldap, or something else.
This way each server would have the appropriate files
which are generated at appropriate times to replace
the static files. This prevents all sorts of extra
overhead incurred to do a dynamic lookup on something
that will most likely still contain the same answer it
did last time and each server maintains autonomy. Static
files are great for data that rarely changes, like email
aliases and domain aliases. Maybe you use LDAP to
manage this central database, but the servers themselves
get their data from the static info files.
You solved your speed issues by throwing hardware at
the problem, which is certainly one option. It takes
away the added responsibility of making sure the script
generation program works right and it gives you immediate
effects on your updates rather than have an extra step.
The downside is you now have another single point of
failure you need to deal with.
If that LDAP server, or network link should fail,
you're hosed, no more mail. So goes the drawbacks of
centrally configured storage. However, as long as you
were throwing hardware at the problem, you could run
slave LDAP servers on each of the MTA machines, that
way, each MTA machine had a local copy of the LDAP store
and used itself as the LDAP server, alleviating the
single point of failure problem as each machine has
now become mostly autonomous again. I don't know what
the overhead of LDAP is like, so I really can't comment
on the efficiency of this approach. It's just one
topology of many that can fit the need. The downside
to this approach is that each server needs to be beefy
enough to run LDAP+MTA. Each cycle spent not delivering
mail, but trying to figure out where to deliver it to is
overhead that you want to eliminate. However, central
configuration saves the engineering team lots of time
which translates directly to dollars.
Just another opinion on the topic, I have made no
decisions one way or the other about which approach
is better as I haven't spent the time with LDAP to
really understand its shortcomings.
-- Michael --
-
----- Original Message -----
From: "Marc Tardif" <[EMAIL PROTECTED]>
To: "Michael Fair" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, April 10, 2001 6:19 PM
Subject: Re: How to route mails to mailboxes that are named [EMAIL PROTECTED]
> Michael Fair wrote:
> >
> > > True, speed of transformation could be an issue for some. On the other
> > > hand, using regexp would defeat the purpose of LDAP.
> > >
> > > For example, lets say you have two addresses which map to the same
> > > mailbox: [EMAIL PROTECTED] and [EMAIL PROTECTED] (this is practical when
> > > people have different domains according to language). If you simply
> > > performed a regexp transformation, gombas_foo_com and gombas_bar_com
> > > would not return the same mailbox. On the other hand, consider the
> > > following LDAP entry:
> > >
> > > uid: [EMAIL PROTECTED]
> > > uid: [EMAIL PROTECTED]
> > > mailfoldermap: gombas_foo_bar_com
> >
> > I can't say that I know how to do it "right",
> > but an equally valid approach is to consider that
> > one domain is the "home" domain and all others are
> > aliases to that domain. In the example above my
> > current configurations (not using LDAP at all) would
> > have first rewritten bar.com as foo.com using a
> > domain alises scheme I set up using exim, then
> > it would have done the regex substition, and tried
> > to deliver the message.
> >
> That is indeed a good idea to solve the domain
> alias problem, but it does not take advantage of
> any of the convenient services provided by LDAP.
>
> Consider for a moment a setup which involves
> more than one machine running cyrus-imapd, would
> you have to keep a distinct alias table on each
> machine to resolve domain aliases? Compare this
> to a centralised approach using a single config
> located in an LDAP directory.
>
> Furthermore, mail retrieval services such as
> imap and pop are only part of an LDAP solution.
> Consider that Postfix might also wish to share
> the domain alias configurations. Would your exim
> approach allow for Postfix and Cyrus-imapd to
> use a single set of configurations, instead of
> creating duplicates?
>
> Let me know what you think, this is still work
> in progress.
> Marc - Sitepak
>
