Re: [exim] Re: Re: Re: Subject rewrite Spamassassin

Page principale
Supprimer ce message
Répondre à ce message
Auteur: Patrick von der Hagen
Date:  
À: exim-users
Sujet: Re: [exim] Re: Re: Re: Subject rewrite Spamassassin
Michelle Konzack wrote:
[...]
> And why do you do that ?
> I call spamd via spamc too and have no problems.
> I do not want to get headache and if spamassassin/spamd can do it...

Then just be happy and celebrate. ;-)
First benefit of using exiscan instead of spamassassin/spamd: you can
reject emails without accepting them, if they are classified as spam.
Using your approach you have to accept the message first, before you can
pipe it so spamassassin. Personally, I wouldn't dare to reject email,
just because it is classified as spam, but that's not the point. ;-)

Second and IMHO more important benefit: using exiscan and adding headers
yourself, can in theory give you an improved performance. Well, "theory"
because I've never actualy done a comparison, but I'm quite confident
that this is one of the rare situations where theory and reality agree. ;-)

Using your approach you
- receive the message (exim)
- create queuefiles
- setup data structures, parse header, etc.
- detect the need to run spamassassin
- start a new spamc-process
- pipe the message to spamc
- remove queuefiles
- spamc connects to spamd
- transfered message to spamd
- spamd modifies message
- spamd transfers message to spamc
- pipe message into exim
- setup datastructures, parse header (again)
- create queuefiles
- finally do some kind of delivery
- remove queuefiles

With exiscan
- receive the message
- create queuefiles
- setup data structures, parse header, etc.
- detect the need to run spamassassin
- connect to spamd and transfer message
- read result (much smaller than modified message)
- possibly modify message
- finally do some kind of delivery
- remove queuefiles

So basically you save several transfers of the complete message, save a
run of the exim parser, create less processes and definitly cause less
disk-io.

By the way, you only get one log-entry for each mail, as each mail is
only processed once. Your approach would process each message twice,
thus getting more log-entries, larger log-files and (again) more disc-io.
Of course, if you have a mere 200 mail-accounts, all of this is probably
of no importance to you.

But in environments dealing with more accounts and more emails, those
improvements can be quite significant.

-- 
CU,
    Patrick.