Quoting Tom Walsh <[EMAIL PROTECTED]>:
> Just a stab in the dark... but what shell do you have for the user vpopmail?
> is it a valid shell or something like /bin/nologin?
> Try using a valid shell for the vpopmail user. maildrop doesn't run setuid
> so it must be run under the shell of the executing user. At least that is
> what I encountered when trying to run maildrop from user level dot-qmail
I read this somewhere on maildrop/courier mailing list. Someone mentioned
exactly what you said, but... You could still specify a mailfilter to maildrop
from .qmail-default (i.e. "| /usr/local/bin/maildrop mailfilter") and in your
mailfilter, you would put SHELL="/bin/sh"
The above would do the same as giving the vpopmail user a shell in /etc/passwd.
Nevertheless, I have also just tried what you just said (for the second time)
and I still get this in my qmail-send logs:
@400000003f7e0d3a331d981c delivery 189: deferral:
I suspect this problem is caused by code compensation for some admins'
stupidity to prevent local DoS in maildrop.
Therefore, I believe the only thing I could do right now is recompile maildrop
with trusted-users="vpopmail ..."
If this is the case, then screw it. I dont want to recompile maildrop
everytime I want to vadddomain -u uniquedomuid newdomain.com
Thanks for your suggestions. If you have any more stabs in the dark, please
feel free :))