>...
>Here's what I'm trying. I'm using MyDNS but added a few fields.
>Basically I'm createing a white list and a black list. The while list
>merely prevents an IP from getting on the black list. An IP gets on the
>whitelist for 12 hours and on the blacklist for 4 hours. The idea being
>to prevent any source that sends any good email from accidentally being
>blacklisted.
>...
Marc,
If you use a bitmasked value, you have (in the common case) 23 bits
to work with. You can use the bottom two bits for three values of "bad"
behavior - please don't use a 4 hour time-out, spam runs last *much* longer
than that; I'd suggest incrementing the bitfield from zero to three for
every spam received and decrementing it approximately every *ten* hours when
no spam shows up (i.e. bad behavior lasts 10 to 30 hours after the last spam).
You can use another two bits for three values of good behavior - if a ham
is recieved and no spam has been for some time, increment the "good" field
and if it is non-zero decrement the bad field; Here you would use a shorter
time period - I'd suggest 8 hours - Thus "good" behavior would be rewarded
for up to 24 hours. Finally a fifth bit could be used to denote known ISPs
and service providers who many have temporary problems (i.e. Yahoo!, Hotmail,
Gmail, etc.).
Your original concept of a 12 hour "good" period and 4 hour "bad"
period is doomed to failure because many spam runs send innocuous messages
at the beginning to test for acceptance by the MX - you would be rewarding
this action by preventing any such spam run from ever causing a "bad" mark
(i.e. spammers would quickly use this tactic if you were successful in getting
your list used, and I for one like the criteria you have proposed for listing;
I just have problems with the timing period suggestions you have proposed).
Further, one more bit with a much longer timeout (3 days to a week)
could be used to immediately escalate repeat offenders back to the maximum
"bad" value.
A scheme like this would allow MTA level choices between a 5xx response
or a 4xx response by comparing the bit mask - e.g. If only "bad" bits are set
send a 5xx, if both bad and good or "well-known" send a 4xx (effectively a
long term greylisting) or let the message be accepted and just score in SA.
Also, scoring is SA for accepted messages (if no MTA blocks are used or occur)
could assign different values for the 32 (or 64) possible combinations.
All of this that I have described would mean keep track of three time
counters: The time since that last spam, the time since the last ham and the
time since the spam counters has been expired to zero.
All of this would use up 6 bits and still leave 17 for any other
purposes you have in mind (assuming codes from 127.0.0.2 to 127.0.0.126).
Paul Shupak
[EMAIL PROTECTED]
