On Tue, 2010-09-14 at 15:41 -0700, Richard Doyle wrote:
> On Tue, 2010-09-14 at 17:03 -0400, Glendon Solsberry wrote:
> > Care to show me where? The only place I see it is part of the
> > spamassassin -D call, and I'm not sure where that came from.
>
> Right, that's where it is, presumably derived from
> 141641-web1.networldalliance.com.
As for "there's no 'http' in the message" from the OP: SA does detect
URIs without protocol. A later normalization will add a version with the
protocol in that case, to help write URI rules -- weather or not the
spammer uses a protocol, it is always safe to use it in your rule.
> The rule is:
> uri URI_HEX m%^https?://[^/?]*\b[0-9a-f]{6,}\b%i
> describe URI_HEX URI hostname has long hexadecimal sequence
>
> URI_HEX is doing what its supposed to do, triggering on a hostname that
> contains a long (at least 6, if I'm reading it correctly) sequence of
> hexadecimals.
>
> Similarly, uribl-black objects to backup.sh
True, and a limitation to some extent -- SA cannot distinct between a
file extension or a TLD. Such FPs are quite rare, bare example.com in an
attempt to go by trivial URI detectors are common.
> I'm not surprised that a message like this hits a number of rules.
*nod* And there is really no reason to process local server originating
messages with SA, is there? In particular cron generated log dumps are
prone to trip over URIBLs (and thus spam scanners) as well as AV
signatures.
Common advice is to bypass scanning them entirely.
If that might be difficult, you should at least adjust your *_network
settings in SA, and add some custom rules to detect local cron stuff, to
offset for such rule hits. Alternatively, whitelist_from_rcvd the
"external" host.
--
char *t="\10pse\0r\0dtu...@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
