Re: [exim] X-Spam-Report for Clean messages

Página Principal
Apagar esta mensagem
Responder a esta mensagem
Autor: W B Hacker
Data:  
Para: exim users
Assunto: Re: [exim] X-Spam-Report for Clean messages
Gordon wrote:

*snip*
>
> Sent with even less detail... the list bounced the reply, sorry for
> duplicates...
>

no sweat..
>
>
>
> Thank you!
>
> 4) adding a specifier as to *which* log, as in the use of :panic: below
>
>       logwrite  = :panic:,VRL,$sender_host_address,$tod_epoch

>
> Lets you put things into the log *you* choose, even if contrarian to
> inbuilt log assignment.
>
>
> Works with two caveats, and a question.
>
> Question the VRL in the example, I can not find any detail so I assume
> it is simple text...


Yes - unique to one of our setups, where VRL = Viral, LBL = Local
BlackList, RBL = Remote BlackList... etc. Used for fast stats from the
SQL DB.

... but left in to demonstrate that you can easily intermix your choice
of text or codes.

>
> 1)
> I got excited about choosing my own log and only succeed in logging to
> panic.log When I choose from defined exim logs it works as expected.
>
> ...:saheaders: and :/var/log/exim/saheaders: both failed...
>
> Success logging to reject.log, some messages may not in fact be rejects
> but... If I put the messages in main.log my logwatch scripts will never
> finish. As it stands they take up to 12 hours to run now.
>


Last time I looked, only the 'standard' main, panic, and reject logs are
selectable with that option - and then only if you haven't handed off
the whole shebang to syslogd.

> 2)
> I have not weighed the impact of this yet, but I am leaning towards
> leaving it as is...
>
> logwrite        =:reject:X-Spam-Score: $spam_score, X-Spam-Report:
> $spam_report

>


Better to write a more terse bespoke message for logging purposes than
to call X-headers. Easier to grep, takes less log space, separates what
Lusers see from what you need internally, 'can be' more CPU efficient.

FWIW - We have SA optioned to not even generate spam reports.

Who ever reads 'em?

> is writing the entire entry on a single line. Useful for grep, not so
> useful for reading.


Reading log entries on a 'single line' benefits greatly from 1440 or
1680 - wide LCD's and terminal sessions with small-but-clear fonts.


Bill