Darin Cox wrote:
Gotcha.  Thanks, Matt.
 
I have another one:  Adding a line to record sender IP/hostname to the log.  Could be useful both for log reports and for building our own sender lists.

The remote IP is already there, but the reverse DNS isn't.  I would think that is more valuable than having the Message-ID like we have now, but Scott's away for a week so I would save such requests for when he gets back.


Also, I've been thinking of some additional tests and considering writing some external tests where needed.
 
1.  If sender address is an ISP (requires a lookup from a known ISP) and from address is another ISP (also determined from a lookup), then fail the test.  Could help identify forging spam.  Main task here is really just building the list of known ISPs.

I too would love to have access to a variable that tracks the From address and not just the Mail From address (is that what you are getting at?).  Currently this would have to be done in an external test which included header parsing to extract the From address since Declude doesn't currently provide that as a variable, though you could pass in the Mail From as a variable.  I'm not sure though what the best approach would be to making use of this data as far as reliable scoring goes.


 2.  If domain is newly registered (configurable), fail the test.  Could help identify spammers who constantly are registering new domains.  I think I remember this idea being discussed on the list within the past couple of months, but I don't know if anyone has implemented anything.

It's been discussed before.  There are ways to query whois data and parse it on the fly, however currently every whois server that I am aware of has limitations that prohibit automated queries.  There is also no caching mechanism for this data, so every time you check a domain, you have to do everything all over again, and that can be expensive.  This would be most useful on domains parsed from the body of messages since the domains in zombie spam are mostly very short-lived and new.

I think what really needs to happen here is for someone to come up with system where you query DNS (for caching), and if a domain isn't contained within DNS when queried, it is sought out and discovered for future queries.  I would imagine that with BIND, you could do this by parsing the logs for non-matches and then automating the queries and subsequent population of the data (Windows can also be set up to log all queries).  In such a system, there should be no reason why you couldn't query Mail From domains, reverse DNS domains, or URL domains.  Also, if you cache the whois data on a centralized server, the number of queries on the registry shouldn't be that high.  I'm game for throwing in some time this if there's a programmer around here that could handle the parsing/querying piece.


 3.  if sender name matches first part of email address (e.g. sender is joe [x.x.x.x], while recipient email address is [EMAIL PROTECTED]) then fail the test.  Could help idenify forging spam.
I think there are much stronger and more common patterns to tag here.  I could be missing something though because zombies do very poorly on my system thanks to Sniffer and a multitude of pattern filters, and RBL's of course.

Lastly, what are people using for honeypots?  I'm assuming most are using program aliases in IMail to extract the info from the emails to build blacklists.  Are there any existing solutions to this or is everyone building them from scratch each time?  I'd be interested in putting together an IMail/SQL Server/DNS-BL system. 

Most around here don't use spam traps, they just look through held messages for patterns or IP's.  Personally I have built a DNSBL/RHSBL that hits almost as often as SBL by simply finding a spammer's IP and then researching it manually so that I can identify whole blocks.  Automating this sort of thing can be quite difficult because spam doesn't always come from servers or zombies operated by spammers.  I've personally opted to go after static spammers, primarily because it is within my means, and because more than 90% of the spam that gets through my system comes from static spammers.

I am not a big fan of automation because the value of a test is greatly impacted by the number and type of false positives.  If you are looking for value from spam traps, Sniffer does a wonderful job and they will tag about 95% of the spam reaching your system and it's well worth paying for it when you might otherwise spend a lot more time building something automated that falls far short of it's accuracy and results.  My only issue with Sniffer is with the false positives.  Because it hits 95% of the spam, there are a fair number of false positives (although relatively few in comparison of hit rates on other tests), primarily on relationship-marketing materials that I don't consider spam, but others report as spam.  These messages also commonly get SpamCopped or fail unreliable tests like FiveTen and SORBS because it's borderline and IMO bad judgement/overzealousness taints all such data.  When you report a false positive to Sniffer, they might remove it from their system, or they will at least remove it from your own unique rule base.  Sniffer does though use SpamTraps to populate their data.

I'm sure that others have all sorts of varying opinoins on these things, so maybe they'll chime in.

Matt



Thoughts?

Darin.
 
 
----- Original Message -----
From: Matt
Sent: Sunday, May 16, 2004 1:40 PM
Subject: Re: [Declude.JunkMail] Logging change request

That was moved in a recent interim release.

Matt



Darin Cox wrote:
I'd like to have the Last Action line in the log moved from LOGLEVEL HIGH to LOGLEVEL MID to reduce the size of logs but still have an easy indicator as to what was done with the message.  Would help greatly with log parsing at MID level, I think.
 
Anyone agree or disagree with this?

Darin.
 
 

-- 
=====================================================
MailPure custom filters for Declude JunkMail Pro.
http://www.mailpure.com/software/
=====================================================

-- 
=====================================================
MailPure custom filters for Declude JunkMail Pro.
http://www.mailpure.com/software/
=====================================================


Reply via email to