On Wed, Nov 15, 2000 at 01:50:19PM +0000, Russell Coker wrote:
> How easy is it to setup Postfix for a large number of dynamically
> configured email domains? What I need to do is to have a mail server
> scale to 10,000 domains over the course of a year, adding 500 new
> domains in a day wouldn't be uncommon for a busy day...
>
> So I need to be able to add domains without (much) reconfiguring of
> the server. Preferrably I would like to use LDAP to specify the
> domains, do the LDAP patches for Postfix support this?
Read /usr/share/doc/postfix/LDAP_README.gz
- everything you seem to want is easily doable.
I've been designing an scalable IMAP server
infrastructure; here are my current plans. Enjoy.
Scalable Mail Servers
*********************
Note: not HA, just scalable.
Based on Postfix, LDAP, Courier-IMAP and maildrop.
"mailsystem" etc are just temporary placeholders for a good software name.
Mail Delivery
=============
Frontend
--------
1..n frontend boxes
Have targetdomains @example.com and @invalid as virtual domains.
virtual_maps = hash:/etc/postfix/virtual, ldap:ldapvirtual
ldapvirtual_query_filter =
(&(mail=%s)(!(|(maildrop="*|*")(maildrop="*:*")(maildrop="*/*"))))
ldapvirtual_result_attribute = maildrop
/etc/postfix/virtual:
example.com dummy
invalid dummy
{NOTE to Russell: you can put the those in LDAP, too. It's all in the
LDAP_README}
ldap entries like:
dn: cn=foo, dc=my, dc=com
mail: [EMAIL PROTECTED]
maildrop: [EMAIL PROTECTED]
Backend
-------
1..m backend boxes, may overlap with frontend boxes. More than one
"logical backend" can reside in the same physical server; e.g. you
may split by the hard disk the mail reside in.
Backend box #42:
virtual_maps = hash:/etc/postfix/virtual-h42
/etc/postfix/virtual-h42:
h42.mail.example.com dummy
@h42.mail.example.com mailuid
h42.mail.invalid dummy
@h42.mail.invalid mailuid
~mailuid/.forward:
|mailsystem-store-mail
mailsystem-store-mail uses env. vars USER, EXTENSION and DOMAIN to:
1. if $DOMAIN/$USER does not exist, search ldap for maildrop=$USER@$DOMAIN and
create maildir or bounce as appropriate.
2. if $EXTENSION set, ensure that subfolder exists; create with maildirmake -f if
necessary
3. store mail in $DOMAIN/$USER/.$EXTENSION/ or $DOMAIN/$USER/ with deliverquota
(fetch quota from LDAP, cache on disk?)
(a bash script could use USERPAD="${USER:0:2}__";
"$DOMAIN/${USERPAD:0:2}/$USER/.$EXTENSION/"
for hashing)
Regularly run a cross-reference between LDAP and actual maildirs, remove maildirs
for which no LDAP entry is found.
Mail Sending
============
Canonicalization
----------------
Shell servers that use UNIX login names need to translate them to
canonical email addresses with proper domains ([EMAIL PROTECTED]
-> [EMAIL PROTECTED]).
sender_canonical_maps = hash:/etc/postfix/canonical, ldap:ldapcanonical
ldapcanonical_query_filter = (uid=%s)
ldapcanonical_result_attribute = mail
ldap entries like:
dn: uid=foo, dc=my, dc=com
uid: foo
mail: [EMAIL PROTECTED]
maildrop: [EMAIL PROTECTED]
Mail Retrieval
==============
Alternative 1: NFS cross-mounts
-------------------------------
/var/spool/mailsystem/hNN.mail.example.com/ etc are cross-mounted between
backend hosts.
All backend hosts serve all users with IMAP etc.
Alternative 2: NFS mounts from common source
--------------------------------------------
/var/spool/mailsystem/hNN.mail.example.com/ etc are mounted from an extra box
to the backend machines, a separate IMAP/POP farm also mounts the dirs.
All mail retrieval hosts serve all users with IMAP etc.
Alternative 3: IMAP/POP frontend passes connections on
------------------------------------------------------
There are frontend IMAP/POP servers that listen for connection, get username
and proxy the connection to the correct backend IMAP/POP server that can access
mail for that user.
No need for NFS mount, atleast not for cross-mounts.
May hinder authentication methods.
Has overhead.
Mail purging
============
Regularly run a batch job that iterates through all users with
(!(purgemail=no)), purge all old mail from Maildir/cur that is
not marked as important ("F").
Do not purge subfolders, so everyone has a safe mail storage method,
not just the people who can modify their LDAP entry.
TODO
====
Reliability?
Mailbox migration? Is it needed?
--
tv@{{hq.yok.utu,havoc,gaeshido}.fi,{debian,wanderer}.org,stonesoft.com}
unix, linux, debian, networks, security, | Stay the patient course
kernel, TCP/IP, C, perl, free software, | Of little worth is your ire
mail, www, sw devel, unix admin, hacks. | The network is down
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
