>...
>From: "List Mail User" <[EMAIL PROTECTED]>
>
>> 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).
>
>Uses up 6 of the 7 bits in that range, Paul. Did you mean 127.0.0.2
>through 127.255.255.254?
>
>{o.o}
>
No I meant 127.0.0.2 to 127.0.0.126; The bitmask '6' would check
the "bad" bits; '24' the "good" bits; '32' for "well-known"; And '64'
for a recent offender. The bottom bit can't be safely used if it can
be set alone (i.e. result in 127.0.0.1) and the top bit isn't needed.
Using the #1 bit (value 2) for any purpose is just redundant and not
needed. (Using bit numbering starting at zero, and drawing little
endian for all of the programmers brought up on Intel documentation.)
So I really did mean the 6 bits as below (warning ASCII art)
128 64 32 16 8 4 2 1
--------------------------------------------------------------------------------
unused recent well-known (good bits) (bad bits) unusable
with all of the possible value of:
2 (one bad msg)
4 (two bad msgs)
6 (three bad msg)
8 (one good msg)
10 (one good and one bad msg)
12 (one good and two bad msgs)
14 (one good and three bad msgs)
16 (two good msgs)
18 (two good msgs and one bad msg)
20 (two good msgs and two bad msgs)
22 (two good msgs and three bad msgs)
24 (three good msgs)
26 (three good msgs and one bad msg)
28 (three good msgs and two bad msgs)
30 (three good msgs and three bad msgs)
32 (well-known - shouldn't occur alone)
34 (well-known with one bad msg)
36 (well-known with two bad msgs)
38 (well-known with three bad msgs)
40 (well-known with one good msg)
42 (well-known with one good msg and one bad msg)
44 (well-known with one good msg and two bad msgs)
46 (well-known with one good msg and three bad msgs)
40 (well-known with two good msgs)
50 (well-known with two good msgs and one bad msg)
52 (well-known with two good msgs and two bad msgs)
54 (well-known with two good msgs and three bad msgs)
56 (well-known with three good msgs)
58 (well-known with three good msgs and one bad msg)
60 (well-known with three good msgs and two bad msgs)
62 (well-known with three good msgs and three bad msgs)
64 (recent offender)
...
then repeat with the recent offender bit set
Since the case of value '32' shouldn't occur, I guess there are only 63
different cases ('96' - a well-known but recent offender would occur).
Any spam arriving with bit 6 set (value '64') would set both
bits 1 and 2 (value '6'). Any spam arriving with either bit 3 or 4
set (values '8' and '16') would decrement the "good bits" field by one
(so a "testing" ham before spam would be at least partially "erased")
*and* increment the value of the "bad bits". Otherwise the bits would
simply increment for each ham or spam received and decrement for each
time counter expiration (with the spam counter needing to be a longer
time than the ham counter - or the "good" field would have to be smaller
than the "bad field" so that the total possible "good" time period is
less than the maximum possible "bad" time period).
Sorry for the complexity, but I spent too much time years ago on
military and other hard real-time systems - most of the constraints I've
expressed are needed to avoid deadlock/live-lock or trivial circumvention
of the system.
In this "system", the best a spammer could do would be to send
three ham and one spam every ten hours, resulting in a value of '18'
when the spam is processed and increasing his connection rate 4 fold.
As long as that value (two good and one bad) still has a slightly "evil"
score (small positive number in SA or an MTA 45x response), there would be
no way to "game" the system. The currently common case of a direct spam
or a single ham with a following spam would result in a value of '2' which
should be an effectively "evil" - guess at a score of ~2 for SA or even a
MTA 5xx or 45x response. Downgrade any SA scores for well-known senders
and never use a 5xx code at the MTA, just 45x for the worst cases (i.e.
long term grey-listing - effectively 10 hours).
Paul Shupak
[EMAIL PROTECTED]
