[ale] Recommendations for mail server w/ LDAP?

mike at trausch.us mike at trausch.us
Sun Dec 2 18:58:22 EST 2012


On 12/02/2012 02:40 AM, Mike Harrison wrote:
> 
> Mike Trausch:
>> Any recommendations for an IMAP server that:
>>
>> (a) doesn't require the use of Maildir or mbox (user mailboxes on
>>     this system average about 20 GB and several hundred thousand
>>     messages may be stored in a single IMAP folder)?
> 
> I'm curious why you don't like Maildir. I'm a little out of date on
> scale email systems, what is now the better way (SQL?)?
> 

Maildir was what we migrated to about four years ago, after a very brief
bout with mbox as the primary mail format and after migrating away from
Google due to hitting their quotas.

The major problem with maildir in _this_ setup is the fact that I
haven't found a filesystem that does well with six-figure counts of
files in directories.  Less than 80,000 or so messages in a mailbox
works just fine.  More than that, well...

... and no, telling them that they cannot have that many messages in a
mailbox is not going to work.  :-)

I wanted to have mdbox w/ Dovecot setup.  The performance
characteristics of such a setup would be almost ideal for us.
Unfortunately, Dovecot doesn't appear to directly interact with LDAP,
and most of the problems that I found reported to the mailing list WRT
LDAP interaction are either ignored or the default answer is "bounce the
LDAP server" or "bounce the mail server" as frequently as required to
keep the mail flowing.  Obviously, such solutions aren't worthwhile.

I tested a fair number of versions of Dovecot with this setup, and it
simply Doesn't Work.  And by "Doesn't Work", I mean to say that it won't
make a query to the LDAP server at all, even when the same credentials
and search filters work just fine with the OpenLDAP "ldapsearch" program.

I've little faith that support in my situation will be any different; I
spent a fair number of hours in the Dovecot IRC channel, too, where mum
is the word.

>> (b) works with LDAP?
>> (c) is well-supported by its upstream?
> 
> I'm a long time user and supporter of the Courier main server and client
> stacks. I used to use it for ISP scale systems (>10 years ago) and am
> running it on my small personal server (about 100 mailboxes for friends,
> family, mailing lists, a handful of customers, etc... It had (and seems
> to still have) a good working LDAP and MySQL auth module. I've used the
> MySQL one, but not LDAP.
> 
> http://www.courier-mta.org/
> 
> I've had good luck using the whole stack, (Courier SMTP, IMAP, POP, etc.. )
> Although it does have it's own quirks (mostly configuration), they are
> documented.
> 
> I really like how it uses sub-directories for config files that make it
> easy to integrate with control systems. It was designed for pretty large
> scale systems. I'm not sure how it compares with other systems, I've
> been using it since about 1999 or 2000.

I'll take a look at it.

The goal is to use Kerberos for authentication, and LDAP for lookup of
(read: validation of presence) user accounts.

It seems that Cyrus handles the solution by side-stepping the need for
LDAP at all.  Instead, you rely on Kerberos for identity verification,
and you define mailboxes by "creating" them for a user, meaning that
there is an additional step to provision mail over simply creating the
user in Active Directory.  This is acceptable to me since I can very
likely find a way to script it, though I'd like something that will
simply be able to check the directory for the presence of the user account.

Our intention is to use Postfix for the MTA, which is capable of
accessing the LDAP server and getting both the primary mail address as
well as aliased mail addresses for the users.  That's great, because it
means we now have a way to eliminate backscatter via simple LDAP
replication to each of the domain's MX servers.  This means that we are
now able to ensure that at the very least, mail will be refused instead
of bounced in the appropriate situations.  We had difficulty with that
before since we were unable to replicate the authentication databases.

Don't get me wrong here:  I'd ___LOVE___ to continue using Dovecot.  But
I (obviously) can't use software that won't work for the job.  I haven't
yet found another IMAP server that knows how to use a format as
efficient as Dovecot's mdbox.  (The efficiency there comes from the
ability to have multiple messages in multiple files; e.g., 20 MB chunks
with as many messages as will fit, which will reduce from 100,000+ files
in a directory to, as best as I can estimate it, perhaps 1,000.)

We _could_ forgo the LDAP setup, but there is a problem there, too:
Dovecot accepts "username" as well as "username at KERBEROS.REALM.NAME"
(but not "username at kerberos.realm.name", go figure) for a user, and it
will create different mailboxes for the users depending on how they sign
in.  We could probably patch Dovecot such that it would treat the two as
one and the same, but that'd mean we're maintaining locally-built
software, and the only locally-built software I'm OK with maintaining is
Samba.  It's trouble enough to maintain _one_ local package for security
patches and the like.

	--- Mike

-- 
A man who reasons deliberately, manages it better after studying Logic
than he could before, if he is sincere about it and has common sense.
                                   --- Carveth Read, “Logic”

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 728 bytes
Desc: OpenPGP digital signature
URL: <http://mail.ale.org/pipermail/ale/attachments/20121202/02bd09fb/attachment.sig>


More information about the Ale mailing list