On Sun, 29 Jan 2006, John Levine wrote:
I've been experimenting with technique that involves combination of
mail server ip address whitelist with greylisting. The idea is by
default to greylist, but once good email is received, the ip address
of mail system is added to special whitelist (I also record name
reported in EHLO but do not use right now) and afterward greylisting
is no longer done and email is processed immediately.
That's close to the usual way to do greylisting. See my CEAS paper
from last year. My greylister doesn't make any attempt to look at the
contents of mail, just remembers the envelope, and if it sees a retry
with the same envelope in a reasonable time window, it succeds and
whitelists the IP.
The original greylist implementation greylists every (IP,sender,recip)
triplet separately, but that never made any sense to me and I always
assumed it is an implementation bug. Once you know that an IP's
client retries, you've learned all you're going to learn from
greylisting and there's no point in delaying any more.
Actually I do store (IP,sender,recip) tripple for greylisting database.
The same server trying to deliver email from the same envelope sender
to different recipient would mean separate greylisting delay. This is
done so that bulk system which sends email with same MAIL FROM but to
different recipients on my system would keep retrying rather then being
able to delivery at once on one of the next runs.
But my whitelisting database is only IP address, so if any emails from
the system is non-spam, it ends up being whitelisted. This is possibly
not that good because in addition to the noted possibility allowing to
probe my content filter (which is probably indeed every rare), this
also easy enough to bypass.
What I'm thinking for one of the next stages is change this whitelisting
ip database into (IP,score) where score is updated and is medium of the
scores of the emails that came from the system before - i.e. it basicly
is a real-time updated reputation system. This reputation score is already
of interest for some other uses (maybe even worth making it public), but
for greylisting its use would be that amount of delay would depend on
this score (i.e. very low score - no delay; medium score - 30 minutes
delay; high score - 6-24 hours delay; very high score - ip is entirely
blacklisted). I'm also thinking this kind of reputation score would
have to degrade with time - i.e. if no emails come from the ip, the score
will decrade and so even blacklisted systems would ultimately get back
into grey area.
Any comments on this?
I intend to write proper software for this reputation system (perl or
python scripts utilizing postgres for backend) next month. If there
is an interst, I can release it. This would be written for use with
spamassassin but greylisting component is obviously separate.
---
William Leibzon
mailto: william(_at_)completewhois(_dot_)com
Anti-Spam and Email Security Research Worksite:
http://www.elan.net/~william/emailsecurity/
Whois & DNS Network Investigation Tools:
http://www.completewhois.com
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg