On 2008-03-28 14:49:40 -1000, Douglas Otis wrote:
On Mar 28, 2008, at 9:22 AM, Matt Sergeant wrote:
On 27-Mar-08, at 5:05 PM, Douglas Otis wrote:
On Mar 26, 2008, at 8:18 AM, Matt Sergeant wrote:
OK, so let me just clarify this - when you are listing a netblock
(and communicating with the owner or whatever you do), you NEVER
periodically re-check that netblock to make sure it hasn't changed
hands or gone quiet or anything? It's just listed permanently
until the heat death of the universe?
[snip]
The following was authored by Dave Rand, who is not an active
participant in this mailing list, but was asked for comment on this
issue. He is available for additional questions, comments or
statistics at dlr_at_kelkea.com.
I have bcc'd him, to avoid getting his email address into any archives
in clear text.
-----
Just before we go off on a tangent, let's remember what RBL listings
(and I'm using the MAPS trademarked RBL now owned by Trend Micro as a
very specific example) are for.
RBL listings are for addresses (or address ranges) which have sent
spam,
From a user's point of view, I disagree. RBL listings are for addresses
(or address ranges) which *will* send spam. Of course that's impossible,
but that's the user's expectation. He doesn't want to know whether a
specific IP address sent spam 3 years ago or even 5 minutes ago. What he
wants to know is whether the message he is about to receive over the
connection that was just opened will be spam or ham. So that is the goal
which RBLs should try to approximate (while knowing that they can never
fully achieve it).
Now, let's look at a few examples, live spam attempts in the last few
minutes. These three examples were not selected in any, other than a
tail of the current mail server log on my system, and happened to come
during the same second.
03/28/2008 16:51:30: SPAM aborted while talking with (200.121.80.112)
- "MAPS RBL".
03/28/2008 16:51:30: SPAM aborted while talking with (210.76.64.22) -
"MAPS RBL".
03/28/2008 16:51:30: SPAM aborted while talking with (88.249.244.18) -
"MAPS RBL".
As it happens, the first one came from an RBL listed address which has
been listed since 2006 - and is still spamming. The second, for more
than a year, and still spamming. The third, for more than a month,
and - you guessed it, still spamming.
This doesn't address the question whether listings should expire.
Of course all of these are still spamming - that was the selection
criterion.
IP addresses, in general, don't "get better" with time. They get
worse.
To prove or disprove this claim, you would need to take a sufficiently
large sample of addresses which were spamming in the past and find out
whether they are still spamming today.
To find out whether the recommendation in the draft ("expire unless
further abuse is observed") is workable you need to find out how many
are still spamming today but are not detectable by your normal listing
mechanism.
As an example, let's assume that from 1000 IP adresses which were listed
6 months ago, 990 are still spamming today. If 985 of them are
detectable by your normal procedure, it is better to automatically
expire. You will now have 5 false negatives, but if you don't you will
have 10 false positives (Of course these 10 IP addresses may never be
used for a legitimate mail server).
I realise of course that these measurements would have to be done on a
global scale to be accurate, and that is impossible.
The blacklist operator can see but a very small part of the internet,
and has no way to determine with any reasonable degree of assurance
that the problem has indeed been fixed - the absence of bad traffic
on a small part of the internet in no way can determine the
"goodness" of an address.
Right.
So, RBL(tm) listings get listed until the problem is fixed, and the
responsible party contacts the blacklisting provider.
If this is the criterion, all you have to do to conform to 2.2.1 is
check your mailbox every 6 months. If nobody has reported that the
problem is fixed, the criterion still applies and you can extend the
listing for another 6 months. (of course the BCP contains other
recommendations, too)
hp
--
_ | Peter J. Holzer | It took a genius to create [TeX],
|_|_) | Sysadmin WSR | and it takes a genius to maintain it.
| | | hjp(_at_)hjp(_dot_)at | That's not engineering, that's art.
__/ | http://www.hjp.at/ | -- David Kastrup in comp.text.tex
signature.asc
Description: Digital signature
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/asrg