[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