RE: [Exim] Exim 4.34 environment variable patch

Pàgina inicial
Delete this message
Reply to this message
Autor: Eli
Data:  
A: 'Exim-Users \(E-mail\)'
Assumpte: RE: [Exim] Exim 4.34 environment variable patch
Hagen Paul Pfeifer wrote:
> * Eli | 2004-06-21 18:09:00 [-0400]:
>
> I think there is no wise exigence for this patch except for debuging
> purpose, maybe.
>
> How many environment variable do you want to set to work effective?
> One, two, ...? More is even error-prone and complex. I think there
> exists better ways to communicate with exim.


Actually it's invaluable here in my position.

I use it (as you could see from my example) that I track some CGI variables.
It kicks in when any client from the local server sends email out, which in
my case is through web forms using the local server to deliver their email.
Since the Apache CGI interpreter sets up these environment variables, they
get tracked with the email (and on my webservers I log this info in the log
files too), so I can tell who sent what since they're able to forge their
From: addresses (I have to let them since the webserver has no knowledge of
their mail server, and the webserver hosts tons of different domains).

I've hacked up a little trick to track PHP generated email as well through
it's mail() function - so now with the environment variable patch, I can
*finally* track all outbound email on my web servers.

I was previously unable to do this - especially with PHP. I can't imagine
life without this patch! It's so much simpler to say "oop, you spammed,
begone" rather than "hmm, I wonder who this is, let me sit and monitor it
for a day..." :P

Oh, and I can't see how it's error prone - it's about as prone to errors as
anything else in Exim - if the person configuring Exim can't figure out how
to set it up properly, then they can enjoy the onset of errors they bought
themselves. The only case for confusion is possibly in some circumstances
where a new shell may be created with no inherited environment, and so the
person will draw back a NULL value rather than something they expected. It
does happen, but so far in my testing (where I see this patch useful) I have
never come across it when I didn't expect it.

Eli.