SpamHash
(bit more detail) |
(.) |
||
Line 36: | Line 36: | ||
=== Testing === |
=== Testing === |
||
− | Some email addresses known to recieve spam were directed into the spamsum spampot and self-filtered. After approx an hour, the spampot cache (emails filtered due to matching emails which were spamsummed (saved to a spamsum cache)) was already at 1:1 ratio of messages with the spamsum cache. After 8 hours spamsum:spampot was 1:2.5. That is, we've caught 10 messages for every 4 we have spamsummed, though the most recent mails are running at a 1:20 ratio (95% effective). I expect the ratio to improve as a larger spamsum history is saved (I expect a history approx 100 times what I had after 8 hours) |
+ | Some email addresses known to recieve spam were directed into the spamsum spampot and self-filtered. After approx an hour, the spampot cache (emails filtered due to matching emails which were spamsummed (saved to a spamsum cache)) was already at 1:1 ratio of messages with the spamsum cache. After 8 hours spamsum:spampot was 1:2.5. That is, we've caught 10 messages for every 4 we have spamsummed, though the most recent mails are running at a 1:20 ratio (95% effective). I expect the ratio to improve as a larger spamsum history is saved (I expect a spamsum history approx 100 times what I had after 8 hours (ie, approx 1 month or 10,000 messages)) |
== Links == |
== Links == |
Revision as of 07:54, 13 March 2009
|
aka SMTP, aka rfc2822
- Some problems associated with email...
- spam.
Solution to spam problem
- spamsum
How does this solve?
A spampot delivery point is known (assumed) to recieve 100% spam. All incoming messages to this mailbox are spamsum'd.
Then as a seperate filter, ALL incoming messages to anyone are spamsum checked against the database of messages generated by the spamsum scores. If the new message rates as "too similar", then it is also assumed to be spam, and dropped. bye bye.
Notes
- The spamsum score db should be rotated. New scores are appended at the end, so approx a week of scores to be kept. (note however that this is would be a flat text file with no internal dates (would spamsum mind if dates are munged in as "not formatted correctly spamsum scores"?), so rotation would likely have to be performed in a "number of lines" manner. Say, 'keep 10,000 scores', rotate daily.
- filtered messages should be kept for sanity checking
Pros
- spamsum is quick, saves message being filtered by heavier bayesian/etc filters
- dynamically reacts to new spam - so long as spampot is sufficiently knowledgable
Cons
- spampot address requires accepting messages we consider to be known spam
- requires totality of message to be accepted
Results
- SMTP Phase
- post-DATA
- CPU Use
- relatively low (significantly lower than, for eg, than any bayesian)
- Memory Use
- low (assumed)
- False Positives
- low (assuming the spampot used to collect spamsum scores isn't corrupted by ham (eg: mailing lists, or email memes)
- Maintenance
- low
- Effectiveness
- good (95% capture rate observed after only 8 hours of testing)
Testing
Some email addresses known to recieve spam were directed into the spamsum spampot and self-filtered. After approx an hour, the spampot cache (emails filtered due to matching emails which were spamsummed (saved to a spamsum cache)) was already at 1:1 ratio of messages with the spamsum cache. After 8 hours spamsum:spampot was 1:2.5. That is, we've caught 10 messages for every 4 we have spamsummed, though the most recent mails are running at a 1:20 ratio (95% effective). I expect the ratio to improve as a larger spamsum history is saved (I expect a spamsum history approx 100 times what I had after 8 hours (ie, approx 1 month or 10,000 messages))
Links
Some good spam reading here:
- A plan for Spam - Paul Graham
- http://www.acme.com/mail_filtering/