Yes, maildrop is owned by root, setuid(/setgid), and mail is a trusted
user (as in the old setup maildrop run as "mail").
These were my easy guesses. Your setup differs from mine, so I can't
give you any working sample config. I can guess some more, though:
Are you sure the LDAP queries are working and returning the values
you expect? Maildrop needs to know the uid and gid of the user and
the Maildir must be writable by that user.
From your original post:
I didn't really understand how the mailfilter file has to do anything
with the user permissions (of course it was world readable)
but I specified it by hand so master.cf now looks like:
maildrop unix - n n - - pipe
flags=DRhu user=mail argv=/usr/bin/maildrop /etc/courier/maildroprc
${recipient}
So maildrop again reads the filter file, but adding some debug
output to
the filter file (whoami, echo $HOME)
it was easy to find out that maildrop can't deliver to the user
maildir
because it runs as user mail and
thinks home directory is /var/mail meaning that maildrop didn't get
anything from LDAP which i don't really understand.
In this case Maildrop runs in manual mode (sans -d) and the $
{recipient} is available as $1 in the rules, but Maildrop won't try
to switch to this user. It will run as user mail as invoked by Pipe.
From your original post:
Oh and I have one more question: when maildrop receives the message
and
gets that the recipient is
xx...@yy.com, does it look up the mail address xx...@yy.com in LDAP,
retrieve
the UID/GID and change to that
UID/GID or does it directly change to user xx...@yy.com?
Maildrop can't switch to user xx...@yy.com, since that is not a valid
username. xx might be, but need not. That's why authdaemond will
query the LDAP back-end for the uid. Confirm that this is really
working: enable enough logging to see what is asked what is the answer.
9 messages in net.sourceforge.lists.courier-maildropRe: [maildropl] per-user uid & ldap
