OT: [Coco] Re: Spam

[Roger Merchberger]

Rumor has it that John E. Malmberg may have mentioned these words:
>Dennis Bathory-Kitsz wrote:
>>At 01:34 PM 1/16/06 +0100, you wrote:
>>
>>>Dennis, any clues?
>>
>>Nope.
>>As I recall, three have slipped through to the maltedmedia list itself in
>>the past two years,

Very good stats - I get about 1 (maybe 2) per week on my Tandy Model 100 
list... but - the list population voted to keep the list "open" as in one 
doesn't need to be subbed to the list to post. Still, with that in mind, 
not too bad...

[snippage]

>This is a trivial to detect trivial forgery, zombie used to do the 
>spamming is spoofing the I.P. address of a mail server in the receiving 
>domain in the hello address.  What should be present is the fully 
>qualified domain of the sending mail server, not an I.P address.

Unless the mail server doesn't have any associated DNS listings, which 
still happens, even in this day & age...

>No real mail server would ever have be saying hello with the I.P. address 
>of a receiving mail server, this so it should be a simple test to reject 
>spam.  I do not know how hard it would be to implement in a mail server.

Depends on the server.

>The SpamAssasin script obviously does not know about this long time 
>spamming script because it should have noticed that it was the same as the 
>receiving mail server I.P. and therefore giving it a score of 100% 
>spam.  This alone would make the rest of the tests a waste of CPU power.

That's not SpamAssassin's job, tho... SA is much too big (and slow) to run 
during the SMTP conversation, well, unless you're Google. ;-) Something 
like that is much easier to integrate into the mailserver anyway - there's 
patches for qmail & postfix, IIRC.

>This appears to be a implementation problem with SpamAssasin, it seems to 
>always run all of it's tests, instead of the minimum needed to classify an 
>e-mail as real or spam.

That's because there might be other rules later that might negate a high 
score to the point where it would classify it as Ham. There are a lot of 
rules that have a negative value, and SA is designed to weigh them all.

>  *  2.0 RCVD_IN_DSBL RBL: Received via a relay in list.dsbl.org
>  *      [<http://dsbl.org/listing?213.85.190.61>]
>
>This is a 99.99% indication that the message is spam.  The only way to get 
>into the list.dsbl.org is to have a confirmed security problem on a machine.

If one trusts list.dsbl.org, then one should run that as a DNS check 
outside of SpamAssassin during the SMTP conversation and not allow the mail 
to begin with. I personally don't know enough about dsbl.org to trust them 
yet.

>... they either do not have a valid rDNS as required by RFC,

rDNS is not *required* by any RFC that I've read...

>  *  2.3 LONGWORDS Long string of long words
>
>Not sure how good this test is.

Not necessarily very good if there's encoded attachments - I don't know how 
good SA is about detecting attachments and excluding them from the tests...

But this entire thread is becoming spam on this list, as it's getting 
*waaaaay* offtopic... [[ Finds clicker, changes channel... ]]

Laterz,
Roger "Merch" Merchberger

--
Roger "Merch" Merchberger   | A new truth in advertising slogan
SysAdmin, Iceberg Computers | for MicroSoft: "We're not the oxy...
zmerch at 30below.com          |                         ...in oxymoron!"