On Sat, 28 Aug 2004, Doug Monroe wrote:
> > On Fri, 27 Aug 2004, Mark Powell wrote:
> > Can someone please confirm that QS 1.23 works fine for them when spam
> > checking emails over 250K? That would help a great deal.
>
> FYI - 300Kb msg sent through one of my systems (QS 1.23, SA 2.63,
> verbose_spamassassin, Redhat 9) fine. Log info below. What OS are you on?
FreeBSD 4.10S.
Sorry, I wasn't clear, I'm talking about fast_spamassassin,
verbose_spamassassin works fine with any size message.
> Your particular problem aside, I agree with the overarching question of
> why you'd push XXMB through SA when it has a known limit of 250Kb.
> Trouble is, that limit could change with next release.
This limit is only an issue when running with fast_spamassassin. In
verbose_spamassassin mode, spamc is piped the entire email on stdin and it
outputs the entire message on stdout. If the message is less than 250k
then it will also spam check it and output the results amongst the
headers. If the message is over 250k then it just outputs the entire
message untouched. Thus in that mode spamc always accepts all the data.
In fast_spamassassin mode all you want from spamc is the spamassassin
results. You pipe it the message on stdin and it simply outputs one line
with the results. The difference is that once it has seen 250k it is not
going to perform a spam check so it simply outputs "0/0" and stops
accepting the surplus unnecessary data. It's this which is causing the
problems.
You can configure the checking limit from its default of 250k with the
-s flag to spamc. Maybe qmail-scanner.pl could use the -s flag and stop
writing after it's sent that much data. That seems unneccessarily
complicated when the QS 1.22 old method worked perfectly. However, it
still seems rather inefficient to have perl read and write an xxMB email
message line by line. Much better to use the 1.22 technique of opening the
email message as stdin for spamc, so it can read the message directly.
It seems the new technique is essentially flawed. Let spamc read the
data itself (afterall it's got to do that anyway) and let it decide when
to stop reading.
Your technique below is even more efficient (and logical) as we don't
even bother running spamc when we already know the results we'll get. I
think that is how 1.24 should handle the spam checking. Currently 1.23 is
broken.
Cheers.
> Thought:
> how about a configurable filesize check before SA with default set at
> current limit of 250Kb?
>
> if ( -s "$scandir/$wmaildir/new/$file_id" > $SAlimit ) {
> &debug("SA: $scandir/$wmaildir/new/$file_id exceeds configured
> SAlimit=$SAlimit...skipping SA check.");
> } else {
> &debug("SA: run $spamc_binary $spamc_options <
> $scandir/$wmaildir/new/$file_id");
>
> open(SIN,"<$scandir/$wmaildir/new/$file_id")||&error_condition("cannot
> open $scandir/$wmaildir/new/$file_id - $!");
> # rest of the SA stuff
> close SA ;
>
> $sa_score='?' if (!$sa_score);
> $sa_max='?' if (!$sa_max);
--
Mark Powell - UNIX System Administrator - The University of Salford
Information Services Division, Clifford Whitworth Building,
Salford University, Manchester, M5 4WT, UK.
Tel: +44 161 295 4837 Fax: +44 161 295 5888 www.pgp.com for PGP key
-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
_______________________________________________
Qmail-scanner-general mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/qmail-scanner-general
