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
> files.

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 :))

Tim Hasson

Reply via email to