On Mon, 1 Jul 2002, Phil Howard wrote:

> How does a delivery agent "hook up" to Postfix? Is LMTP the only way,
> or can it be a dynamic library?

Either LMTP, or a UNIX command line invocation via "pipe" (the
delivery agents that come with Postfix use the internal queue manager <->
delivery agent IPC, they also directly touch the queue file and bounce
logs). The internal interfaces are not documented and are subject to
change, so at this time only "LMTP" and "pipe" are suitable for
"third-party" delivery agents. In practice this is good enough.

>
> What about local_recipient_maps and/or making smtpd reject unknown users
> when the delivery is keeping separate users spaces for each domain (which
> apparently is what is called virtual).
>

If the VDA recipient tables are available via a suitable Postfix map type,
"smtpd" can validate recipients against these tables. The "userdb" format
used by Courier is available (via a patch) as a Postfix map type. One day
there may be an interface for dynamically loading new map types.

> 1. Support for many domains.
>
> 2. Support for separate user name space for each domain (except where
> a domain is linked/aliased to another, then they share the user
> name space).

Any VDA will do 1 & 2.

>
> 3. NOT one giant map with every userdomain. That will be too big to
> maintain. A separate map for each domain is best.

Your intuition is wrong here. Searching multiple (possible hundreds) of
maps for a single key scales poorly. In fact one single map is best.
Making a sensible front-end tool that provides per domain views is a
separate problem (can use say "select ... where ..."). A good IMAP server
comes with virtual user and virtual domain administration tools.

>
> 4. Mail delivered to ${prefix}/${domain}/${user}/ in maildir format

Any VDA will do this, but for some the mailboxes for each user may need to
be explicitly mapped to the appropriate path.

>
> 5. If ${prefix}/${domain}/${user}/ exists, the address is valid for
> delivery. If it doesn't, then the address is non-existant.

This cannot be done from "smtpd", it needs to be able to run "chrooted"
and with low privileges. You need a map to validate the users. Surely
users need a password entry to read their mail, so a path entry for their
mailbox is not asking too much. Any multi-column database (MySQL, LDAP,
userdb, ...) will be able to all the necessary data in one row per user.

>
> 6. If ${prefix}/${domain}/${user}/.forward exists, obey it.

This is available with some VDAs (but not the "virtual" delivery
agent bundled with Postfix).

>
> 7. One single system user owns everything from ${prefix}/ on down.

        $virtual_uid_maps = static:12345
        $virtual_gid_maps = static:12345

> To carry out some of these things, the thought I had was to write a new
> map type handler which does a lookup for an existing directory or file.
> The "name" for the map will actually be a complex specification that
> tells the path, what to return if the file object does not exist, what
> to return if it is a directory, and what to return if it is a file with
> a special code to indicate that the file should be read and its content
> be returned. Then Postfix can think it is a map, but it's just a directory.
>

This will not work because of "chroot" and security issues. Just drive
both the VDA and Postfix from a shared "userdb", MySQL or LDAP database.

> Users will be added/deleted/changed by web CGI programs. Rebuilding a
> whole map is a bad idea in this case.
>

Berkeley DB maps support incremental insertion, but this is not
crashproof unless you turn on logging and transactions, doing Postfix
compatible locking may also be an issue, also Postfix may need to open
the map with logging and transactions turned on in order to do crash
recovery, this is not the case with the current Berkeley DB <-> Postfix
glue. For live incremental updates your best may be LDAP, MySQL or (via a
patch) PostSQL.

Note on the other hand that even large Berkeley DB maps can be rebuilt
from scratch very quickly (5s on my machine for ~16MB on disk .db file
with ~140000 records). If you build a copy of the map, open it, sync it,
and rename it, you have a light weight crash-proof (atomic) Berkeley DB
rebuild. If this happens infrequently (less than once every 5 minutes) you
will be better off with Berkeley DB than with any complex/slow DBMS than
supports incremental insertion of records.

Does anyone else have good experiences with other dynamic map types that
support efficient frequent incremental rebuilds and are robust against
crashes?

[ Michael Tokarev: how quickly does your tinycdb build large maps ~100000
rows ~16 MB image ].

-- 
	Viktor.
-
To unsubscribe, send mail to majordomopostfix.org with content
(not subject): unsubscribe postfix-users

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]