You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Chris <cp...@earthlink.net> on 2004/07/01 02:08:36 UTC
Re: spamd kills box
On Tuesday 29 June 2004 08:27 pm, George Georgalis wrote:
> >I wonder if there is something about that message that is hard on SA?
> >It is attached as uuencoded file KMAMQDMXXVGHNIGCLYSH=hotmail.com.txt
>
> begin 600 KMAMQDMXXVGHNIGCLYSH=hotmail.com.txt
> M1G)O;2!V=G1A87IJ971Z0&AO=&UA:6PN8V]M(%1U92!*=6X@,CD@,3DZ,SDZ
> M,#`@,C`P-`I296-E:79E9#H@9G)O;2!C<&4P,#`S-#<S834X,F8M8VTP,&4P
> M-F8Q8C!C9#8N8W!E+FYE="YC86)L92YR;V=E<G,N8V]M("@V.2XQ.34N.3<N
> M,C(U*0H@(&)Y(&EU>'1A+F-O;2!W:71H(%--5%`[(#(Y($IU;B`R,#`T(#(S
Must be because the little message below took 43.6 secs to process, while
the norm now seems to be between 3.5 and 11 seconds. I stil question
though why it seems to take so long to process a 'clean' message as opposed
to a 'spam' message, almost twice as long it seems.
----9420391856849388962
Content-Type: text/plain;
Content-Transfer-Encoding: base64
dGhpcyBsaW5rIHdpbGwgTWFrZSB5b3Ugfjo6OkI6Okk6R35+DQoNCg0KaHR0cDovL2cubXNu
LmNvbS8wVVMhczkucGFyYXhpYWxfM2NoZWVycy9NWS5jb2ZmZXI/aHR0cDovL3JhZmFlbC5p
bmZvbWF4eC5uZXQ6ODUvYWx3YXlzbGFyZ2UvDQoNCg0KdGhpcyBpcyB1bnN1YnNjcmliZSBs
aW5rLg0KDQpodHRwOi8vZy5tc24uY29tLzBVUyFzOS5jb21ldGFyeV8zY2hlZXJzL01ZLmxp
bmRiZXJnP2h0dHA6Ly9jaG9pcm1hc3Rlci5pbmZvbWF4eC5uZXQ6ODUvYWx3YXlzbGFyZ2Uv
bGVhdmUvDQoNCg0KNV9oWzEw
--
Chris
Registered Linux User 283774 http://counter.li.org
7:03pm up 2 days, 21 min, 2 users, load average: 0.53, 0.36, 0.38
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dying is one of the few things that can be done as easily lying down.
-- Woody Allen
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Live - From Virgin Radio UK Virgin Radio Classic Tracks - The original
classic rock station
Re: spamd kills box
Posted by Chris <cp...@earthlink.net>.
On Wednesday 30 June 2004 09:59 pm, David B Funk wrote:
> On Wed, 30 Jun 2004, Chris wrote:
> > Must be because the little message below took 43.6 secs to process,
> > while the norm now seems to be between 3.5 and 11 seconds. I stil
> > question though why it seems to take so long to process a 'clean'
> > message as opposed to a 'spam' message, almost twice as long it seems.
>
> Ham processing takes longer than spam for the same reason that:
> That missing watch/keys/wallet/glasses is always found in the -last-
> place that you look. (IE you stop as soon as you find it ;).
>
> SA in general looks for spam signs in a message. There are very few rules
> that look for ham signs.
>
> When running a particular spam rule, the regex search engine stops as
> soon as it has found a hit -or- when it has searched all possible data
> in the message. Thus with ham, you have to run all rules to exhaustion,
> in spam just until you find the first match for each rule.
>
> You will particularly notice this with SpamCopURI. It does the
> DNS lookups on every URL's host until it finds one that gets a
> 'hit'. So if it finds a spam-host in the first URL, it's done.
> In ham, it does the DNS checks on all the URLs (with the attending
> possible network delays with each DNS operation ;).
Thanks Dave, I understand now
--
Chris
Registered Linux User 283774 http://counter.li.org
10:12pm up 2 days, 3:30, 2 users, load average: 0.21, 0.37, 0.42
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Men use thought only to justify their wrong doings, and speech only to
conceal their thoughts.
-- Voltaire
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Re: spamd kills box
Posted by John Andersen <js...@pen.homeip.net>.
On Wednesday 30 June 2004 18:59, David B Funk wrote:
> You will particularly notice this with SpamCopURI. It does the
> DNS lookups on every URL's host until it finds one that gets a
> 'hit'. So if it finds a spam-host in the first URL, it's done.
Perhaps it should be reprogramed to process from the
bottom up.
(donning pith helmet, diving for cover)...
--
_____________________________________
John Andersen
Re: spamd kills box
Posted by Jeff Chan <je...@surbl.org>.
On Wednesday, June 30, 2004, 7:59:06 PM, David Funk wrote:
> You will particularly notice this with SpamCopURI. It does the
> DNS lookups on every URL's host until it finds one that gets a
> 'hit'. So if it finds a spam-host in the first URL, it's done.
> In ham, it does the DNS checks on all the URLs (with the attending
> possible network delays with each DNS operation ;).
It's probably worth mentioning that recent DNS implementations
cache hits and non-hits (NXDOMAIN) so that many lookups for a
given URI probably only need to be fully resolved once within a
few days. The DNS performance of then-cached hits or non-hits
should be pretty good, assuming the same query (i.e., the same
message URI) occurs more than once.
Jeff C.
--
Jeff Chan
mailto:jeffc@surbl.org
http://www.surbl.org/
Re: spamd kills box
Posted by David B Funk <db...@engineering.uiowa.edu>.
On Wed, 30 Jun 2004, Chris wrote:
> Must be because the little message below took 43.6 secs to process, while
> the norm now seems to be between 3.5 and 11 seconds. I stil question
> though why it seems to take so long to process a 'clean' message as opposed
> to a 'spam' message, almost twice as long it seems.
Ham processing takes longer than spam for the same reason that:
That missing watch/keys/wallet/glasses is always found in the -last-
place that you look. (IE you stop as soon as you find it ;).
SA in general looks for spam signs in a message. There are very few rules
that look for ham signs.
When running a particular spam rule, the regex search engine stops as
soon as it has found a hit -or- when it has searched all possible data
in the message. Thus with ham, you have to run all rules to exhaustion,
in spam just until you find the first match for each rule.
You will particularly notice this with SpamCopURI. It does the
DNS lookups on every URL's host until it finds one that gets a
'hit'. So if it finds a spam-host in the first URL, it's done.
In ham, it does the DNS checks on all the URLs (with the attending
possible network delays with each DNS operation ;).
--
Dave Funk University of Iowa
<dbfunk (at) engineering.uiowa.edu> College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{