I think the biggest problem with his draft is the following:
For blacklists, an obvious approach would be to limit the granularity
of DNSBLs, so that, say, each /64 had a separate listing, and the
queries only used the high 64 bits of each address. While this might
limit the damage from DNSBL queries, it is not helpful for DNS
whitelists, which by their nature list individual IP addresses, and
are likely to be far more popular with IPv6 mail than they have been
with IPv4 mail.
A host that is a legitimate host and thus deserving of being in a
whitelist will not be enumerating every single IP address in a /64,
one-per-message, the way that a spammer in a blacklist would be.
Thus, we can safely make the assumption that any mailserver is going
to follow the model of a single host per /64. Thus it will ALSO be
just as useful for whitelists to have the same granularity - a /64 -
as it would be for blacklists.
What this really calls for is a reworking of the SpamAssassin code.
SA is going to have to start caching the results of any IPv6 DNS
BL queries for a set period of time, probably 2 days. Any IPv6
address in a BL needs to invalidate all other IPv6 addresses in
the /64 that the IPv6 address is in for 2 days. There is no need to do
further querying, nor is there a need for the scheme enumerated in
the RFC draft.
Ted
On 12/29/2010 12:09 PM, Matthias Leisi wrote:
Hi all,
I'm not sure whether that would be more appropriate for the dev list,
but I guess this is relevant/of interest to the SpamAssassin project,
and I don't know whether this has caught attention here yet.
John in his draft mentioned below is very right to point out that
simply applying the IPv4-DNSxL paradigm to IPv6 has the potential to
drain resources from DNS caches. Especially, a spammer may cause DNS
caches to fill with "useless" data by enumerating /128s in a /64
interface, and thus causing a spam filter to start DNS queries for all
those /128s.
I'm not yet convinced that John's proposal of a B-tree search encoded
in DNS TXT records is really a good choice (it adds a lot of
complexity to a previously extremely simple protocol), but maybe it's
the best approach given the requirements.
It makes most sense to discuss the proposal on the ASRG list. However,
SA will be a major user of this protocol, so likely some
implementation ideas can be discussed here as well.
Personally, I'm also open for other ideas or approaches that make it
feasible to query reputation lists in an IPv6 world, be it over DNS or
some other transport protocol.
-- Matthias
---------- Forwarded message ----------
From: John R. Levine<jo...@iecc.com>
Date: Wed, Dec 29, 2010 at 5:48 PM
Subject: [Asrg] draft-levine-iprangepub-01
To: Anti Spam Research Group<a...@irtf.org>
I've done another version of it, with mostly editorial changes.
Comments as always welcome. I guess now I should implement it.
http://tools.ietf.org/html/draft-levine-iprangepub-01
Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly
_______________________________________________
Asrg mailing list
a...@irtf.org
http://www.irtf.org/mailman/listinfo/asrg
