> -----Original Message-----
> From: Philip Hazel [mailto:ph10@cus.cam.ac.uk]
>
> On Wed, 7 Jan 2004, Eli wrote:
>
> > The only problem is... I see no way of accessing environment
> > variables in Exim?
>
> That is because Exim is called in unpredictable environments, and
also
> because it is called from user (i.e. potentially hostile)
> environments.
> Relying on environment variables seems rather dangerous to me.
I wasn't thinking of actually relying on any of the environment data
to have Exim react differently depending on it. I just saw it as a
sure-fire way to track certain variables that I knew would exist (CGI
variables in my case) to track information which may help me if one of
the users started to send out spam through my system.
> > However, it still would be nice to be able to do something like
> > $env_<environment variable> to access env vars in places.
>
> I think this would be utterly confusing. People would think they
could
> do this in routers and filters. But if a message is delayed, the
> environment is different when the next delivery happens from a queue
> runner. Or do you think the environment should be preserved with
each
> message?
You're right - it was even confusing for me in a way when I thought
PHP would export them even if it was an Apache module (not running as
a CGI), but I was wrong. Also, I never even thought about the case of
a message being deferred/delayed and a retry happening later causing
the environment to be different. Preserving an environment would be a
big waste of space for something potentially not required, since it
could contain huge variables (LS_OPTIONS comes to mind for certain
Linux'es) that would get stored somewhere for each and every message.
I'd say don't bother preserving any environment settings - not worth
the trouble the way I see it (esp since it would be almost guaranteed
that the environment will be different when a retry happens compared
to initial delivery). My only intention was for use in ACLs during a
local system call (see my later email on how I used them).
I still think that these would be of *some* use though - just as I had
used them. The code that I wrote seems to work fine, and it's hardly
any code at all, so hopefully it wouldn't hurt to keep it (although I
think it would be nicer if rather than $env_blah, that it was a
function like a lookup, to avoid the little kludge I just added to
which probably isn't wanted :P). I would just say stick some nice
blue warning text in the documentation noting that environment
variables can be very unpredictable because of retries and such.
If the patch is added though, I was thinking of putting in some more
code so that def: checks would work as well... only makes sense :)
It was just a stab in the dark to try and cope with the horrid task of
trying to track down spammers who use local sending on webservers (PHP
is just horrid for this - I *am* going to have to make an extensive
patch to their mail() function to accommodate tracking features).
Any other input (anyone!)? Thanks Philip!
Eli.
---
[This E-mail scanned for viruses]
