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: maildrop:_Changing_to_/home/vpopmail/Message_start_at_0_bytes,_envelope_sender= vpopmail/maildrop:_Attempting_.mailfilter/maildrop:_Delivering_to_/var/mail/vpo pmail//usr/local/bin/maildrop:_Unable_to_open_mailbox./ 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 :)) Respectfully, Tim Hasson