On Nov 7, 2008, at 3:17 AM, Stephane Bortzmeyer wrote:
On Tue, Nov 04, 2008 at 10:59:46AM -0800,
The IESG <[EMAIL PROTECTED]> wrote a message of 26 lines which
said:
- 'DNS Blacklists and Whitelists '
<draft-irtf-asrg-dnsbl-07.txt> as a Proposed Standard
Well, it is certainly very important that the DNSxL are documented,
given their widespread use. And the I-D is a good document.
On the other hand, I have a few questions: the first one, why
"Proposed standard"? Is it really a good idea to standardize these
lists (most being badly managed)? Why not just "Informational" if we
just want to document what people are doing?
Agreed.
Second question, the document indeed standardizes many things which
are not in common use but does not point towards a rationale, so
some choices are puzzling. Why TXT records to point to an URL and
not NAPTR? Is this because of current usage in DNSxL? If so, this
should be noted. But why IPv6 lists use a A record and not a AAAA? I
am not aware of existing IPv6 lists so this cannot be the current
usage?
In putting together planning for IPv6 block-lists, one soon confronts
the enormity of its potential data-set and the incredible complexity
related to carrier grade NATs, tunneling protocols, and third-party
translation services. :^(
On the other hand, the DKIM signature "domain" and an accurate "on-
behalf-of" value as a tuple offers a safer and simpler basis for
acceptance with perhaps only a two order increase in the data-set. In
today's budget cutting and tight schedules, even establishing a DKIM
list is not easy where ADSP needs to be modified before this can
happen. :^(
Perhaps years from now, part of the overhead for sourcing from IPv6
will be to include DKIM signatures with accurate "on-behalf-of"
values. The "on-behalf-of" values should be opaque in most cases.
Today it would seem email wants to pretend to authenticate, rather
than indicate what is actually authenticated, even when using opaque
values. :^(
It is seldom that a person's email-address represents the source of
abuse. Instead, it is often the result of compromised systems
somewhere in the message stream.
-Doug
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
