Mailing List Archive

On Thu, Feb 12, 2004 at 01:25:58PM -0500, spamassassin is rumored to have said:
>
> Something I did notice though was that a few kb email received a huge
> 38pts. Now, I didn't do any time tests on that email to check how long
> it actually took to process, but I'm assuming longer than one that only
> scored a little over 5pts.

Someone more intimate with the code would be better prepared to give an accurate answer, but I have to ask why it would take longer. All the same tests are being run, DNSBLs being queried, razor checks, etc. Whether or not a test result is positive should have little or nothing to do with how long it takes to run.

> Should there be an option to tell
> spamassassin to stop checking and tag the email after it has received a
> 5pts limit? Kind of a "Why keep looking at it after I know its spam?".

This is asked pretty frequently on this list. The answer is pretty basic - how do you know it's spam if there are still tests (some of which can reduce the score) that need to be run? Say I get a newsletter that's got the Habeas SWE mark in the headers (-8.0), but it gets 7 pts for content, before the Habeas test is run, and SA stops there. If I'm /dev/null'ing my spam, I'll never see that newsletter that I really did want.

I don't know what order the tests are run in, but I'd prefer that SA run all it's tests before it decides that a message is or isn't spam.

St-


--
"In the End, we will remember not the words of our enemies, but the silence of our friends."
- Martin Luther King Jr. (1929-1968)

Thanks for the good info. Makes sense to me now. Spamassassin awesome
software. I'm just playing devils advocate for a minute. Seems like
there is somebody always out there trying to break something.

Steve Thomas wrote:
> On Thu, Feb 12, 2004 at 01:25:58PM -0500, spamassassin is rumored to have said:
>
>> Something I did notice though was that a few kb email received a huge
>>38pts. Now, I didn't do any time tests on that email to check how long
>>it actually took to process, but I'm assuming longer than one that only
>>scored a little over 5pts.
>
>
> Someone more intimate with the code would be better prepared to give an accurate answer, but I have to ask why it would take longer. All the same tests are being run, DNSBLs being queried, razor checks, etc. Whether or not a test result is positive should have little or nothing to do with how long it takes to run.
>
>
>>Should there be an option to tell
>>spamassassin to stop checking and tag the email after it has received a
>>5pts limit? Kind of a "Why keep looking at it after I know its spam?".
>
>
> This is asked pretty frequently on this list. The answer is pretty basic - how do you know it's spam if there are still tests (some of which can reduce the score) that need to be run? Say I get a newsletter that's got the Habeas SWE mark in the headers (-8.0), but it gets 7 pts for content, before the Habeas test is run, and SA stops there. If I'm /dev/null'ing my spam, I'll never see that newsletter that I really did want.
>
> I don't know what order the tests are run in, but I'd prefer that SA run all it's tests before it decides that a message is or isn't spam.
>
> St-
>
>

>>
>>This is asked pretty frequently on this list. The answer is pretty basic
>>- how do you know it's spam if there are still tests (some of which can
>>reduce the score) that need to be run? Say I get a newsletter that's got
>>the Habeas SWE mark in the headers (-8.0), but it gets 7 pts for content,
>>before the Habeas test is run, and SA stops there. If I'm /dev/null'ing
>>my spam, I'll never see that newsletter that I really did want.
>>I don't know what order the tests are run in, but I'd prefer that SA run
>>all it's tests before it decides that a message is or isn't spam.
>>St-

If you run your tests in ascending order of score, wouldn't you eliminate
this objection? All negative tests would be run before the positive ones,
so once you hit the cutoff you'd know that it really was spam.

However, I think the cutoff should be separate from the trigger value... I
do various things for different scores using tmda.

> If you run your tests in ascending order of score, wouldn't
> you eliminate
> this objection? All negative tests would be run before the
> positive ones,
> so once you hit the cutoff you'd know that it really was spam.
>
> However, I think the cutoff should be separate from the
> trigger value... I
> do various things for different scores using tmda.
>

The score is the total of the rules, so how can you know the total before
all the rules finish? I understand what you are saying but it ends up
causing spamassassin to be less accurate.

At 01:25 PM 2/12/2004, spamassassin wrote:
> Something I did notice though was that a few kb email received a huge
> 38pts. Now, I didn't do any time tests on that email to check how long it
> actually took to process, but I'm assuming longer than one that only
> scored a little over 5pts.

That's not a very valid assumption.

All the rules get run regardless of how many hit, and that's what takes time...

Yeah, you probably added a few hundred CPU clocks to the report generation,
but that's fractions of a microsecond.

>I am wondering if it would be possible for a spammer / dos virus to flood
>a smtp server with a email that was crafted in such a way that it would
>score as high as possible and or find tests that take longer than others
>while maintaining a very small file size. I'm imagining that, enough email
>would make a server crawl and start causing smtp timeout problems.

No.. processing time is a mostly a function of the time it takes to run the
rules, not the number of matches.

You can probably craft an email to force the slowest path possible through
the ruleset regexes, but this won't be a significant add to the processing
time.