ietf-asrg
[Top] [All Lists]

Re: [Asrg] 2. Improving Blacklists and Reputation Services

2004-02-10 23:38:58
On Tue, Feb 10, 2004 at 02:01:59PM -0500, Yakov Shafranovich wrote

What bothers me is that these codes vary from list to list. Would a 
standard set of codes help?

  Back in the days of the DNSbl-BCP sublist, I proposed a rough draft
for certain metadata.  Right now 127.0.0.2 seems to be the de-facto
standard for single-purpose zones, where a binary YES/NO is sufficient.
Aggregate zones are a special case, depending on what they want to do.
For the SORBS example, adjacent IP addresses are the way to go.
zz.countries.nerd.dk is trying to encode a numeric result.

Second problem that I have is the use of 127.xxx IP addresses
for this.  This is really not something that should be done via
IP addresses, a custom SRV, RR or TXT record would server a much
better purpose.

  Don't forget that the internet is global, and there are many languages
and character sets for that matter.  Should TXT messages be in English
or Chinese ?  Which character set ?  Please justify.  On the other hand,
numeric codes, in the form of an IP address can be interpreted in any
language.

We should explore other protocols beside DNS for exchanging this data.

  If we can find a better mousetrap, by all means.  The major advantage
of DNSbls is that they can be implemented without basic changes in the
infrastructure.  That is a problem that has caused grief with many
anti-spam proposals.

I am actually looking at things like SenderBase and SpamCop

  Puh-lease, not Spamcop and SenderBase.  Those two are are absolute
jokes...

  - Spamcop, in it's early days, sent off complaints to IANA about spam
    originating from 10.0.0.0/8.  They've filtered such obvious junk,
    but I still don't trust them.  SpamCop is marketed to newbies who
    don't know how to parse headers.  As long as it relies on newbie
    users who can't parse headers, I will not trust them.  Like all
    automated software, it can produce some howlers.  People who can
    parse headers can catch the mistakes, newbies can't.  AOL gets
    blocked every now and then.  As a matter of fact
    http://www.spamcop.net/bl.shtml specifically states...
"This blocking list is somewhat experimental and should not be used
in a production environment where legitimate email must be delivered."

  - SenderBase, what can I say about them.  I've read quite a few posts
    by people I trust, saying that SenderBase has listed IP addresses
    that have never been used by mailservers.  OK, so that's 2nd hand
    stories.  Look up the following two URLs...
http://www.senderbase.org/search?searchString=0.0.0.0%2F16
http://www.senderbase.org/search?searchString=169.254.0.0%2F16

and click on the IP addresses they list.  Those damn spammers at IANA
again<g>.  Their listing is *MUCH* less of a joke today than it was back
in December, when there were tons of listings in RFC1918 and multicast
space.  If they've merely applied filters to zap obvious errors, I still
have reason to question the overall reliability of Senderbase listings.

  In other words, those two are the absolute last DNSbls I would use.
They are great for setting up strawman arguments about why DNSbls are
bad, but I wouldn't use them on my incoming email.  SPEWS produces less
collateral damage, fer-cryin-out-loud.

-- 
Walter Dnes <waltdnes(_at_)waltdnes(_dot_)org>
Email users are divided into two classes;
1) Those who have effective spam-blocking
2) Those who wish they did

_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg



<Prev in Thread] Current Thread [Next in Thread>