On Tue, 17 Nov 1998, Lars Kellogg-Stedman wrote:
> Hmm. The problem I reported occurs even with no_verify set; if I read
> your reply correctly, exim shouldn't be processing the forward file
> with this option set.
Sorry. I was confused there. Exim handles addresses given via EXPN in
the same way as the -bt option rather than the -bv option. That is, it
tests them as for delivery rather than in the special "verify" mode used
for incoming mail.
> It looks like there may be a bug in exim's handling of the no_verify option.
There is certainly a bug - it shouldn't be obeying logwrite when doing
address testing. I will fix that. The documentation should also be
clearer about no_verify and EXPN.
Meanwhile, you can circumvent the problem by setting the option no_expn
on the forwardfile director. Like no_verify, this should probably be set
in the default configuration, and I will put it there for future
releases.
> When processing a filter file as the result of EXPN or VRFY, why doesn't
> exim simply run under the appropriate uid/gid, as it would if it were
> delivering mail?
Because it can't. The daemon has used setuid() to give up all its
privilege permanently and irrevocably. This makes sense - it needs no
privilege to read messages and write to its spool. People who know much
more about security than I do will tell you that giving up privilege
temporarily via seteuid() is a dangerous thing. There are even those who
believe there is never any reason to make use of seteuid() at all
(though Exim does use it). Anyway, on general principle there is no need
to retain privilege when it is not needed.
When it is delivering mail, Exim does have to hold on to its privilege,
in order to run the delivery processes as the appropriate uid/gid.
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
--
*** Exim information can be found at
http://www.exim.org/ ***
