On Mon 27.07.2009 22:11, Chris Lewis wrote:
Aleksandar Lazic wrote:

.
push (@{$related->{$uniq_key}->{'TO'}},$1.'@'.$2);
.
.
Of course if there  is a better way for the correleation I'am open for
suggestion ;-)

The thing is that unless you have only one long-running qpsmtpd
process, you can't "see" the records from other instances.

Especially, say, with qpsmtpd-async with more than one child.  In that
environment, you could have several thousand simultaneously open
sessions spread amongst dozens of separate qpsmtpd processes.  They
can't see the other processes' memory spaces.

You'd have to push/pull the data to a centralized process.  Eg:
separate daemon.

Ick. Mostly ;-)

Having a plugin fire a UDP packet to a daemon which collects, analyses
them, and stuffs 'em where qpsmtpd can get data back from (eg: a file)
would work.

Well I don't think that is so difficult, but I'am not sure.
I will take a look this weekend and post my solution for the discussion.

[snipp]

I'am not sure, due the fact that I haven't use sendmail for long
time, but sendmail had al this information in one line I think ;-)

In modern sendmail you need to grab three records to get a full record
of an email.  Sendmail logs are a PITA.

Maybe, I don't know, I belive you.

But with a hacked log_terse plugin in qpsmtpd you will get one
easy-to-parse record with everything you want.  My qpsmtpd
implementation only emits a single line to the logs per email (plus
occasional processing errors).

[snipp]

Thanks, I will definitly take a look for a easy to use and robust
solution.

BR

Aleks

Reply via email to