On Thu, Apr 22, 2010 at 3:12 PM, Stan Hoeppner stan@hardwarefreak.comwrote:
With this many lookup table types supported by Postfix, is it true that it has no "simple" table type in common with Dovecot?
There are some ... like mysql for example. The ones I call "simple" are ones that have a single file in some readily contructable form. These include btree (Berkeley DB) and cdb (Dan B's CDB). Others could be included but I haven't looked at them, yet (such as cidr, which has specific purposes, only). Things I consider "not simple" involve making a network connection. It can certainly be simple to configure them. But I'm classifying these in terms of the number of things going on to get the answer. Even a DB scheme to use a DNS lookup (not implemented for Postfix) I would consider as "not simple" here, even though it is likely very simple to do. The tcp scheme is probably the simplest of the network schemes (but it requires something to listen somewhere). If I were asked what I think could be added to this list of lookup schemes, it might be a long, long thread. Let's not do that here.
unix (read-only)
A limited way to query the UNIX authentica- tion database. The following tables are implemented: unix:passwd.byname The table is the UNIX password data- base. The key is a login name. The result is a password file entry in passwd(5) format. unix:group.byname The table is the UNIX group database. The key is a group name. The result is a group file entry in group(5) format.
This is "simple", too. But the problem is it isn't flexible enough. Dovecot supports this scheme and can use it on any specified file. Postfix is limited to just the system files (and is probably using Unix library calls to access it, hence the source of the limitation).
I would think the general (insert some character here)-separated file should be doable: comma-delimited:/some/file/name colon-delimited:/some/file/name tab-delimited:/some/file/name space-delimited:/some/file/name But it hasn't been done that I can see (some third party patch not withstanding).
Anyway, I need to re-study what is involved with the virtual users, since I may have to be doing this in Postfix just to get submission authentication to work, and then see how that affects using local_recipient_maps. And at this point it's probably more of a SASL issue than a Dovecot issue. So back to reading Postfix docs (including the SASL reference someone gave) and asking on the Postfix M/L if needed (not here, this is for Dovecot). It may well be the description given early to use Dovecot SASL to authenticate Postfix submission users would be just fine, as long as Postfix does a SOFT rejection when Dovecot isn't up, so it requeues files. On the SMTP end, I just want an up front rejection decision to avoid backscatter. The one backscatter hole where an existing user is being deleted while incoming mail is being queued is probably insignificant.