On Wed, 2006-08-30 at 23:48 +0200, Josip Rodin wrote:
> On Wed, Aug 30, 2006 at 08:34:03PM +0200, Micha Lenk wrote:
> > >Ah, there's the catch - the -d option. It makes maildrop switch to the
> > >specified user's home directory. The user isn't actually specified, but I'm
> > >assuming that since Exim sets $USER to the value of $local_part, this makes
> > >maildrop deliver to the user the mail is being delivered to.
> > >
> > >However, I'm not actually sure that the maildrop process is executed *as*
> > >the said user, but instead it runs as the Exim user ("Debian-exim"), but
> > >writes files under the specified user. (This default is documented under
> > >"Generic options for transports" in the exim4 info manual.)
> >
> > I verified your statements about Exim4 and I can confirm that the target
> > program of pipe deliveries is executed as the (implicit, if
> > check_local_user is used) specified user and that environment variables
> > like USER are set accordingly.
>
> That's not actually "confirming", you know :) One of Greg's original mails
> states that the router calling the transport has check_local_user, so
> the execution happens as the user (rather than as Debian-exim), and that's
> all right.
>
> Except that it's still unclear what the original problem could have been
> *shrug*
>
> The only remaining difference that I can think of is that the -d option is
> doing something screwy with those 30% users that makes them work properly
> under courier-maildrop, and that it is failing to do that with normal
> maildrop. Greg? Are all your users alike, or are some configured with
> something extra in relation to Courier or other authentication databases?All of my $HOMEDIR/.mailfilter users are local " Pluggable Authentication Modules" users or PAM users. They are all local users with shell accounts. If they make it through PAM, they are good to go. Therefore if the domain being serviced has shell accounts, they exist in /etc/passwd. No additional Courier setup is used for them. In fact no additional Courier setup is used for the rest of my setup either. I use the default setup for Courier except the self signed and generated SSL Certificate for imaps and pop3s And I think the Original-original problem was the suid wasn't there, causing exim4 to fail to execute the program as the user to deliver as wanted. But has since morphed into a problem with now running but delivering to /var/mail... (or something similar) or failing with a timeout. BTW, local users are supposed to be force into a $HOMEDIR/Maildir delivery setup. So no mail goes into any files-system other than /home. The rest of the users I have are virtual and are not able to use .mailfilter or any other dot files. It(the virtual stuff) is all DB/Flatfile driven and have many other options. They are also partitioned to a separate file-system and have quotas set. Getting back to the point though, I can install "maildrop" and see what still occurs. This would be on Sarge currently. I might be able to force a different newer version if you think it might help. I'd have to give a heads up to my users, to allow them to cope. -- greg, [EMAIL PROTECTED] The technology that is Stronger, better, faster: Linux
signature.asc
Description: This is a digitally signed message part
