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