>>>>> "PIR" == Peter Radcliffe <pir@???>
>>>>> "PH" == Philip Hazel <ph10@???>
PH> Problem: It forks the subprocess and sets the uid/gid before it
PH> runs the transport. So this wouldn't fit easily in the code.
PIR> Not even as a special case a'la :blackhole: ?
Looks like right up in the generic stuff you would be doing things
like
if ((transport == appendfile) &&
(local_part == "/dev/null"))
blackhole();
This seems very messy. Where was the /dev/null coming from, and why
did that address have no uid/gid associated with it (ie can the
problem be better fixed elsewhere?).
PH> Only makes sense if
PH> the user can read *and write* the spool files.
PIR> The file could be chowned to the user first, or copied and then
PIR> coied back (but that doesn't make much sense for huge messages
PIR> ... so don't edit huge messages :)
Why not just restrict it to things where the user does have write
permission (probably via group membership).
[how often do you edit messages - I must admit I have *never* used this]
PH> Nothing. I've just, this very day, added code to make it send
PH> EHLO if it sees "ESMTP", and take some notice of SIZE. There
PH> didn't seem any point in sending EHLO when it wasn't going to
PH> make use of what came back, and when, prior to the "ESMTP in the
PH> banner" convention, you had to play lots of nasty games to cope
PH> with broken old MTAs.
Need to be careful. There are still boxes that curl up and die when
they see this - hence the convoluted code in smail (if other end dies
when you say EHLO then reopen connection immediately and only use
HELO). However in general ESMTP is a "good thing" (tm)
[Has anyone noticed my domain - good-thing.tm ??]
Nigel.
--
*** Exim information can be found at
http://www.exim.org/ ***
