On Wed, Aug 30, 2006 at 11:01:41AM -0400, Greg Folkert wrote:
> > > Here is the transport for maildrop run out of EXIM:
> > >
> > > maildrop_pipe:
> > > driver = pipe
> > > command = "/usr/bin/maildrop"
> >
> > I also noticed that this transport doesn't have a user definition of
> > any kind. You can add these options:
> >
> > user = $local_part
> > group = mail
> >
> > so that Exim runs maildrop as the user who receives the e-mail.
> > Otherwise, I'd wager that it would try to deliver mail as the system user
> > "Debian-exim", which doesn't sound like something you'd want for all users.
>
> The entry in the default exim4 config is as follows, as confirmed by
> Marc Haber and Andreas Metzler:
>
> [EMAIL PROTECTED]:transport]$ pwd
> /etc/exim4/conf.d/transport
> [EMAIL PROTECTED]:transport]$ cat 30_exim4-config_maildrop_pipe
>
> maildrop_pipe:
> debug_print = "T: maildrop_pipe for [EMAIL PROTECTED]"
> driver = pipe
> path = "/bin:/usr/bin:/usr/local/bin"
> command = "/usr/bin/maildrop -d"
> return_path_add
> delivery_date_add
> envelope_to_add
>
> This is one of the transports that are default in the config.
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.)
So unless you did chmod u+s on the maildrop binary (making it setuid root,
and able to switch users itself), then something would be wrong.
Note that such a setup (maildrop being setuid) isn't recommended.
Instead, you can and should use Exim's internal setuid/setgid code to switch
to the $local_part user, and leave maildrop unprivileged.
That way you also won't need the -d option, unless you have user information
stored somewhere else other than the normal stuff (that is, database in
/etc/passwd and stuff). In the latter case, -d will cause maildrop to link
to other Courier stuff to find users.
> I gave up on trying to use the "maildrop" package and just used the
> courier-maildrop package. Just to move on and get things done. It maybe
> that maildrop and courier-maildrop are not interchangeable... but when
> they conflict and are seen as equivalents for things, it would be hard
> pressed to not assume this.
It's possible that there was more of a difference back in 1.5.x, but I don't
have enough information to confirm that.
> If you see fit, you may close this, unless you really want to fix it to
> work the way it should with exim4 out of the box. Either by adding a
> commented out part for the "maildrop" package in the default exim
> transport (/etc/exim4/conf.d/transport/etc/exim4/conf.d/transport) or by
> changing maildrop to work with the method.
I'll ask the Exim4 guys about their recipe, esp. given some other changes
introduced recently in maildrop 2.x.
I hesitate to close the bug report, since we didn't actually accomplish
much. Perhaps later when you confirm or deny some of my interpolation
above :)
--
2. That which causes joy or happiness.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
