- The interesting part -- I am invoking LDA from Maildrop. See:
http://thread.gmane.org/gmane.mail.imap.dovecot/65473 So when invoked, Maildrop has already dropped to the destination UID/GID and the needed paths are available in the environment. However, using as many permutations of calling LDA as I can think of (based on http://wiki2.dovecot.org/LDA ), I always get this:
(command line usage error. Command output: lda: Fatal: Couldn't lookup our username (uid=2500) )
I could not find anything in the mailing list archives to help me, but I googled and found a link to a source file:
http://hg.dovecot.org/dovecot-sieve-1.1/raw-rev/7d85833eff96
I read the source, it looks like it's not exactly a userdb lookup - LDA is trying to get the unix username for the given UID. In my case, UIDs are "virtual" so there isn't a unix username. The source doesn't really use the username that it looks up except in a call "open_logfile."
Is it possible to avoid this problem? It looks like the answer is no, I have to use -d which also forces a userdb lookup. Maybe this limitation can be removed in the future? Now I suppose I have to go understand the problems of userdb lookup permissions, but I think there are solutions for that.
FWIW, in this scenario, "service auth" in master config has to have its mode relaxed to 0606 to make userdb lookups work. So ANYONE on the machine can see all userdb lookups. I don't have local users here, so it's probably safe anyway(?).
Can anyone explain if there are other security risks of running the auth service at 0606?