Philip Hazel wrote:
>On Wed, 26 Jan 2005, Toralf Lund wrote:
>
>
>
>>13:07:54 135071 expanding: ${lookup{$local_part}lsearch{/etc/aliases}}
>>13:07:54 135071 result: :include:/usr/local/etc/mail.jokes
>>13:07:54 135071 expanded: :include:/usr/local/etc/mail.jokes
>>13:07:54 76363 LOG: MAIN PANIC DIE
>>13:07:54 76363 unable to set gid=4 or uid=998 (euid=93): system_aliases
>>router (recipient is jokes...)
>>13:07:54 76363 SMTP>> 421 Unexpected failure, please try later
>>
>>- that's for a slightly different address from the one mentioned earlier, but
>>one that's configured in the same manner.
>>
>>This leads me to believe that Exim does try to execute under the ids specified
>>via "user" and "group", but somehow fails. I think the problem goes away if I
>>remove these settings, so I'm now trying to find out if that has any undesired
>>side effects. Comments?
>>
>>
>
>That leads me right to the answer, which of course I should have known,
>but it did not spring to mind right away.
>
>The answer is that if you specify a user for a redirect router, Exim
>insists on using it when reading an :include: file. This means that you
>cannot use :include: with a user setting for verification, because at
>that time, Exim is running as "exim", and it cannot change uid. (It
>might work if you set user=exim.)
>
>
Fair enough. As long as I understand what's going on, I'm fairly
happy... And I should be able to find a way around the problem.
Actually, I may not need to specify user at all. I think I did so in the
past because the exim user was root, and I'd rather run alias pipes as a
non-privileged user, or perhaps exim would change to "nobody" by default
- I forget which.
>The only solutions you have are (a) don't specify the user (or try
>user=exim); or (b) don't use :include:, at least not when verifying. You
>could set up two different routers, one for verifying and one for
>delivering, though that's a bit messy.
>
>
Anyhow, thanks for the help.
- Toralf
