As requested. I suppose I could grab the queue ID and back track to the sender but when the logs get long (which they do, half a million or more lines) these scans can take a while and I'm trying to capture this info in real time (more or less):

I'm trying to come up with mechanisms to catch compromised accounts sending SPAM. Since spammers don't necessarily have all good addresses a large number of their SPAM messages bounce with 550 errors (mailbox unavailable or doesn't even exist). I would
like to monitor men logs and catch that pattern. The problem is that the log entry that includes the 550 error only shows where the message was intended to go and not where it came from. That's found on another log entry line. Is there anyway to tweak the
logging mechanism so both bits of data appear on the same log line?

Thanks.

Rob
Tanner

UNIX
Services Manager
Linfield College, McMinnville Oregon

ITS will never ask you for your
password. Please don’t share yours with anyone!

Benny Pedersen

... big logs can still be grepped, it works well for postfix-logwatch and pflogsumm if you tweek the logs its pointless to grep info from it later, if logs are

Message 2 of 6
, Jun 14, 2013

0 Attachment

Rob Tanner skrev den 2013-06-14 00:18:

> As requested. I suppose I could grab the queue ID and back track to
> the sender but when the logs get long (which they do, half a million
> or more lines) these scans can take a while and I'm trying to capture
> this info in real time (more or less):

big logs can still be grepped, it works well for postfix-logwatch and
pflogsumm

if you tweek the logs its pointless to grep info from it later, if logs
are big, rotate more, eg rotate hourly ?

--
senders that put my email into body content will deliver it to my own
trashcan, so if you like to get reply, dont do it

Your message has been successfully submitted and would be delivered to recipients shortly.