maildrop missing maildir path in authldaprc

The first thing I would do is increase the verbosity of the Postfix logs and find the exact command that Postfix is using. Make sure it's the same as the one you are using when do this by hand. Please post a log snipped (not entire verbose logs) showing what Postfix is doing.

Ok, when you run this command everything is fine
here the command wich runs ok

 cat /etc/issue | maildrop -V 6 -d <email address hidden>

part of the authlib log running this command

maildrop: authlib: groupid=5000
maildrop: authlib: userid=5000
maildrop: authlib: <email address hidden>, home=/srv/vmail/domains, mail=domain.tld/testmail/Maildir/
maildrop: Changing to /srv/vmail/domains
...

The master.cf file of postfix relative to maildrop

...
maildrop unix - n n - - pipe
  flags=DRhu user=vmail:vmail argv=/usr/bin/maildrop -w 91 -d ${recipient}

Postfix log

Jun 24 08:41:24 server postfix/cleanup[11117]: 132D064372: message-id=<email address hidden>
Jun 24 08:41:24 server postfix/qmgr[10043]: 132D064372: from=<email address hidden>, size=359, nrcpt=1 (queue active)
Jun 24 08:41:24 server authdaemond: Authenticated: sysusername=<null>, sysuserid=5000, sysgroupid=5000, homedir=/srv/vmail/domains, <email address hidden>, fullname=Testmail, maildir=domain.tld/testmail/Maildir/, quota=52428800S, options=<null>
Jun 24 08:41:24 server postfix/pipe[11118]: 132D064372: to=<email address hidden>, relay=maildrop, delay=18, delays=18/0.02/0/0.03, dsn=2.0.0, status=sent (delivered via maildrop service)
Jun 24 08:41:24 server postfix/qmgr[10043]: 132D064372: removed

...

Then, maildrops put the email in a file Maildir, in /srv/vmail/domains, this is wrong.
I´m using amd64 arch.
As you can see even when the authdaemond says this maildir=domain.tld/testmail/Maildir/ postfix fails to run ok the maildrop.

Could this be permissions related? When you run the command by hand what
user are you?

Postfix drops it's root privileges after binding to port 25 for security
reasons.

Running the command as root:
root@server:/srv/vmail/domains/domain.tld# cat /etc/issue | maildrop -V 6 -d <email address hidden>
maildrop: authlib: groupid=5000
maildrop: authlib: userid=5000
maildrop: authlib: <email address hidden>, home=/srv/vmail/domains, mail=domain.tld/testmail/Maildir/
maildrop: Changing to /srv/vmail/domains
Message start at 0 bytes, envelope <email address hidden>
maildrop: Attempting .mailfilter
maildrop: Delivery complete.
The mail goes ok, and is received in the Maildir correctly, now if runs as user vmail, wich is the user postfix uses to run maildrop as in master.cf...
flags=DRhu user=vmail:vmail argv=/usr/bin/maildrop -w 91 -d ${recipient}
...
Running the command as vmail:
su - vmail

$ cat /etc/issue | maildrop -V 6 -d <email address hidden>
maildrop: authlib: groupid=5000
maildrop: authlib: userid=5000
maildrop: authlib: <email address hidden>, home=/srv/vmail/domains, mail=domain.tld/testmail/Maildir/
maildrop: Changing to /srv/vmail
Message start at 0 bytes, envelope sender=vmail
maildrop: Attempting .mailfilter
maildrop: Delivering to ./Maildir
maildrop: Flock()ing ./Maildir.
maildrop: Appending to ./Maildir.
maildrop: Delivery complete.

The mail fails, goes to a file Maildir in
srv/vmail/domains/Maildir
with the email in the file Maildir, I mean as a file not a directory...

The path permissions:
root@server:/# ls -l /srv/vmail/
total 32
drwxr-sr-x 3 vmail vmail 4096 2007-06-24 12:10 domains
drwx------ 2 vmail vmail 16384 2007-05-18 07:19 lost+found
-rw------- 1 vmail vmail 56 2007-06-24 12:12 Maildir-----This file is where the email goes
root@server:/#

root@server:/srv/vmail/domains# ls -l
total 8
drwxrws--- 3 vmail vmail 4096 2007-06-24 08:35 domain.tld
root@server:/srv/vmail/domains#

root@server:/srv/vmail/domains/domain.tld# ls -l
total 4
drwxrws--- 3 vmail vmail 4096 2007-06-24 08:35 testmail
root@server:/srv/vmail/domains/domain.tld#

root@server:/srv/vmail/domains/ubil.reduim.cu# cat /etc/passwd | grep vmail
vmail:x:5000:5000::/srv/vmail:/bin/sh
root@server:/srv/vmail/domains/ubil.reduim.cu#

root@server:/srv/vmail/domains/ubil.reduim.cu# cat /etc/group | grep vmail
vmail:x:5000:vmail
root@server:/srv/vmail/domains/ubil.reduim.cu#

Any ideas?

Sorry, in my last message where you see ubil.reduim.cu is domain.tld

I did, a chmod 777 -R to /srv/vmail/domains, but nothing, maildrop is only working ok with user root, as vmail fails.

For some unknown reason when running as root it gets the home correctly from ldap in
/srv/vmail/domains

maildrop: authlib: <email address hidden>, home=/srv/vmail/domains, mail=ubil.reduim.cu/testmail/Maildir/
maildrop: Changing to /srv/vmail/domains

but when running as vmail it gets as homedir the unix user home of vmail, not from ldap:
/srv/vmail

maildrop: authlib: <email address hidden>, home=/srv/vmail/domains, mail=ubil.reduim.cu/testmail/Maildir/
maildrop: Changing to /srv/vmail

This is really crazy...

I'm wondering if this bug relates:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=235007

Why don't you see if setting uidNumber and gidNumber in your /etc/courier/authldaprc makes a difference.

I use in authldaprc
##NAME: LDAP_GLOB_IDS:0
#
# The following two variables can be used to set everybody's uid and gid.
# This is convenient if your LDAP specifies a bunch of virtual mail accounts
# The values can be usernames or userids:
#
# LDAP_GLOB_UID vmail
# LDAP_GLOB_GID vmail
LDAP_GLOB_UID vmail
LDAP_GLOB_GID vmail
I don't have a user id for each ldap account, I use a global vmail that's why I don't use LDAP_UID and LDAP_GID

##NAME: LDAP_IDS:0
#
# Uncomment the following, and modify as appropriate, if your LDAP database
# stores individual userids and groupids. Otherwise, you must uncomment
# LDAP_GLOB_UID and LDAP_GLOB_GID above. LDAP_GLOB_UID and LDAP_GLOB_GID
# specify a uid/gid for everyone. Otherwise, LDAP_UID and LDAP_GID must
# be defined as attributes for everyone.
#
# LDAP_UID uidNumber
# LDAP_GID gidNumber

Any way I tried with
LDAP_UID uidNumber
LDAP_GID gidNumber

And still the same

My /srv/vmail is a mount point:

/dev/sda2 on /boot type ext3 (rw)
/dev/sda5 on /home type ext3 (rw)
/dev/sda6 on /opt type ext3 (rw)
/dev/sda8 on /srv/www type ext3 (rw)
/dev/sda10 on /tmp type ext3 (rw)
/dev/sda9 on /usr type ext3 (rw)
/dev/sda11 on /usr/local type ext3 (rw)
/dev/sda12 on /var type ext3 (rw)
/dev/sda13 on /var/lib type ext3 (rw)
/dev/sda14 on /var/log type ext3 (rw)
/dev/sda15 on /var/spool type ext3 (rw)
/dev/sda7 on /srv/vmail type ext3 (rw)

# /dev/sda7
UUID=d87f358a-c98e-4334-b9f5-8f6be7e01666 /srv/vmail ext3 defaults 0 2

root@server:/etc/courier# ls -l /srv/
total 8
drwxrwsr-x 3 vmail vmail 4096 2007-06-24 15:31 vmail
drwxr-xr-x 3 root root 4096 2007-05-18 07:19 www

The only other potentially relevant Debian bug I can find is this one:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=223371

I wonder if it somehow relates to socket permissions.

Bits of this thread might be relevant too:

http://sourceforge.net/mailarchive/forum.php?thread_name=460712F9.4020203%40amfes.com&forum_name=courier-maildrop

Searched for sockets permissions but, it seems no problems, searched the log for permission deanied but nothing..
root@server:/var/run/courier/authdaemon# ls -l
total 4
-rw-r--r-- 1 root root 6 2007-06-24 16:55 pid
-rw------- 1 root root 0 2007-06-22 14:52 pid.lock
srwxrwxrwx 1 root root 0 2007-06-24 16:55 socket

Active UNIX domain sockets (only servers)
Proto RefCnt Flags Type State I-Node Path
unix 2 [ ACC ] STREAM LISTENING 38714 /var/run/courier/authdaemon/socket.tmp
unix 2 [ ACC ] STREAM LISTENING 38563 public/cleanup

...
Any ideas?

At this point I'd suggest looking in the archives of the Courier mailing
lists for ideas and ask there if you don't find anything. Please let us
know how it works out.

Searching courier maildrop install I saw this:

When using the standalone maildrop build with courier-authlib, one of
the following configurations must be used:

* Your mail server must invoke maildrop as the root user (the -d flag
reads the mail account's uid and gid, then drops root) .
* Manually change the permissions on the maildrop binary to be setuid root.
* Manually change the permissions on the courier-authlib's socket
directory (/usr/local/var/spool/authdaemon by default) to be globally
readable or executable.

The default permissions on courier-authlib's socket directory blocks
world-access to the filesystem socket connected to courier-authlib's
authentication daemon process. In order for maildrop to connect to the
authentication library, maildrop must either have root privileges
(which will be temporary, as soon as maildrop determines the account's
userid and groupid, it will drop root, before reading the maildroprc
file), or courier-authlib's socket directory must have world read and
execute permission.

Note that if the permissions on the socket directory are changed,
anyone on the system can connect and obtain any account's password!

It is the system administrator's responsibility to choose the
appropriate security policy when using the Courier Authentication
Library.

Also I saw it must be a list of trusted user to do this??

Well a workaround wich works, but you must consider the security risks is by allowing user postfix and vmail call aildrop without password in sudoers:
/etc/sudoers
#
vmail ALL=NOPASSWD: /usr/bin/maildrop
postfix ALL=NOPASSWD: /usr/bin/maildrop

And change in postfix master.cf the maildrop service
  flags=DRhu user=vmail argv=/usr/bin/maildrop -w 91 -d ${user}@${nexthop}

to

  flags=DRhu user=vmail argv=sudo /usr/bin/maildrop -w 91 -d ${user}@${nexthop}

I don't like this way, but all the options has security risks, is something it must change in courier, since all the options in the Install in delivery mode, are really risky.
-- Call maildrop as root and it later changes
-- Setui root maildrop
--Glocal read and executes in authdaemon socket.
The only way I did this to work in feisty is throught sudo.
I will appreciate a help for a more secure way.
Best regards

There's a new courier version in gutsy. Is this still an issue.

[Expired for courier (Ubuntu) because there has been no activity for 60 days.]

I believe this is fixed in the current version. If it's still a problem, feel free to reopen the bug.