* Josip Rodin <[EMAIL PROTECTED]> [2006-08-28 17:22]: I've tried to
> reproduce it now, and it seems that it's a full-blown link instead of
> a dynamic open. Please install courier-authlib in the meantime. I'll
> investigate if it should become more optional.
Ok, I have installed it to test once again.
> > temporary failure. Command output: ERR: authdaemon: s_connect() failed:
> > Permission denied /usr/bin/maildrop: Temporary authentication failure.
> What user are you running maildrop with? That's what I meant by "even
> then you need a privileged user to run it, I think."
maildrop is only run by one local user, from his .forward file.
> [...] But more to the point, what user are you trying to run
> maildrop -d with, and what is your expected behaviour? What do you
> expect from the -d option?
-d ${USER} in .forward has been used because of a suggestion to do so in
MAILDROP_README of the postfix distribution... I guess this is not
correct (with recent maildrops).
> Since the initial bug report says you run it from a .forward file, can you
> instead try simply omitting the -d option altogether?
When -d is omitted, this works ok (when courier-authlib is installed).
Thanks for clarifying this.
The last thing I do not understand is that the maildrop that had been
compiled and installed manually is not suid at all, and the -d ${USER}
works ok. I guess this is because the ${USER} is replaced by same id as
the one owning the maildrop process (this is the same user). The doc of
maildrop seems to tell that this case of using -d is ok.
But with the debian version (2.0.2), this doesn't work, so this seems
related to courier-authlib... With my own compiled version, I do not get
the ERR: authdaemon: s_connect() failed: No such file or directory
/usr/bin/maildrop: Temporary authentication failure. error at all when
using -d ${USER} in .forward.
Thanks for your help,
--
Damien Wyart
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
