[Mimedefang] SpamAssassin via mimedefang is slow

Daniel Bourque dbourque at weatherdata.com
Fri Nov 7 11:16:07 EST 2008


Interesting , then maybe the speed difference lies in network tests 
being done the Received and Return-Path headers.


Not sure what I could gain from having spamassassin check Received and 
Return-Path headers .  Our main smtp relay does the DNSBL checks at the 
sendmail level, and mime-defang does relay checks to skip filtering for  
internal e-mail.


but, for the sake of sanity, I will pre-pend them and see if that's 
what's causing the slowdown.

plus, it needlessly triggers SA rules:

Milter change (add): header: X-Spam-Score: -0.001 
MISSING_MID,NO_RECEIVED,NO_RELAYS


Thanks

Dan


Jonas Eckerman wrote:
> Daniel Bourque wrote:
>
>> All tests are performed and get the same report, score, etc... Not 
>> sure what's going on with spam_assassin_check, it's doing a lot more 
>> elaborate
>
> Are you sure that the tests performed are the same?
> Have you checked wether or not network tests are really the same for 
> both ways of calling SA? Network tests can take some time, expecially 
> if you don't have a local caching DNS proxy/server.
>
>>    open(IN, "./INPUTMSG") or return 0;
>>    while ( <IN> ) {
>>            @message = <IN>;
>>        }
>>    close(IN);
>>
>>    my $spamtest = Mail::SpamAssassin->new({
>>            userprefs_filename => "/etc/mail/sa-mimedefang.cf"});
>>
>>    my $mail = $spamtest->parse(\@message,0);
>
> If you're running MIMEDefang in your border MTA you should prepend a 
> Received-header to the message before having SA parse it. Otherwise SA 
> will not know wich relay you got the message from.
>
> It's possible that the difference in speed is because you are now 
> running with netrwork tests disabled though, wich would make the 
> importance of correct path information less than it'd otherwise be.
>
> I'd also suggest prepending a Return-Path header.
>
> Regards
> /Jonas



More information about the MIMEDefang mailing list