On Fri, Apr 23, 2010 at 2:49 AM, Rainer Frey rainer.frey@inxmail.de wrote:
On Thursday 22 April 2010 18:15:18 Phil Howard wrote: [ ... all standard stuff that is well documented ... ]
- Passwords stored encrypted, such as MD5. And it should be a scheme that both Postfix and Dovecot can use so I don't have keep two different encryption schemes.
Postfix doesn't need any password directly. It only authenticates a user with a password in one case: SMTP SASL authentication of submission users, and it uses the dovecot auth service for that and does not read the password database itself.
OK, so all that is in whatever SASL configuration, and so I'll be doing that in Dovecot.
It is not about supporting a certain database library. There is simply a
difference in what Dovecot and Postfix need from a user/recipient database. Dovecot needs information like path to mailbox, uid/gid with which to put files into the mailboxes, extra configuration fields ... Therefore it uses a structured multi-value format like the passwd-file. CDB or similar don't work like this, so dovecot can't easily support using the same CDB files as postfix.
Why not have all those fields combined into the value string you get from CDB? If it can do it from a line out of /etc/passwd then it can do it from CDB (the value could simply be that same line ... or defined to be something else more convenient).
Postfix only supports name:value tables, either to use the value
(table-style lookup) or to check whether there is an entry for a name (list-style lookup). Therefore it only uses file databases with such a mapping. In the case of valid recipients which will be handed off to dovecot for delivery, it is such a simple list lookup.
The value can be a tuple (see above). We're lucky that what Postfix needs is "does this exist". So it can just completely ignore the value and not need any code to parse it.
(If it interests you: the postfix virtual delivery agent needs very similar information to dovecot, but it uses several key:value maps for the different information, all with the recipient as key.)
I've run into that before. I think it was the source of some difficulty. In programming I've done, I've stored structured data in Berkeley DB and never needed but one table/file per class of index.