søn, 03.07.2005 kl. 14.53 skrev Jasper Slits:
[...]
I suspect the user 'maildrop' cannot read the authdaemon socket. It's
located in /usr/var/authdaemon/socket (using debian), but its location is
probably different with other distributions.
After using 'strace -o /tmp/maildropdebug maildrop -V5 -d us...@domain.tld
< message.eml', you can look at /tmp/maildropdebug to see the actual path..
In my case it looks like this:
connect(3, {sa_family=AF_FILE, path="/var/run/courier/authdaemon/socket"},
110) = 0
Good call and almost certainly right, but: On my RHAS3 rig with all the
courier stuff installed from self-made rpms (using Sam's rpm specs) the
socket's in /var/spool/authdaemon/ (now why would it be in run?)
Make sure it's readable by the maildrop user, and a recursive chmod on
/var/run/courier should do the trick.
Do NOT do a recursive chmod on /var/[run|spool]/courier. Or on the
authdaemon dir, for that matter. The socket needs to be a socket and
have world read/write permissions, the overlying directory has 770
perms, owner daemon group postfix on my rig. But that's because the
maildrop binary is suid,sgid root - perhaps not so sensible.
--Tonni
9 messages in net.sourceforge.lists.courier-maildropRe: [maildropl] Postfix/maildrop driv...
