Nick Nicholas wrote:
you may make your comments inline if desired
Okay, you get it then in source order, from typo to whatever
else I might see.
whitelists of of IP addresses or domains. This memo discusses
s/of of/of/
create and maintain DNS-based reputation systems ("DNSBL") of IP
addresses and domains identified as problem sources of email. These
Some DNSBLs are in fact "DNS based lists" used for other purposes
like Geo location. If you haven't done it later you could note
that you're not talking about the general "DNSBL" concept.
These DNSBLs vary widely in integrity, strategy, methodology and
s/These// They all vary widely.
7. What are the demographics and quantity of the list's user base?
How are admins supposed to evaluate this ? Sounds bogus for me.
9. What do your peers or members of the Internet community say
about the list.
They all say it's bad for various conflicting reasons, none of them
related to any incident in the last five years.
If a system or network administrator allows a third party to make
blocking decisions for its network, then the administrator MUST
understand the policies and practices of those third parties
because responsibility for blocking decisions remain ultimately
with the administrator.
Yes. And actually a list does NEVER make blocking decisions for a
list user, because nobody is forced to use it. How about "uses the
proposals of a third party to make blocking decisions".
These guidelines address public DNSBLs only and do not apply to
privately operated DNSBLs.
s/do/may/ ? Some proposals should also make sense for private lists.
Therefore readers should be aware that this document
does not necessarily represent the consensus of the
entire ASRG.
Is that necessary ? As a BCP it will have IETF consensus no matter
what the ASRG situation might be.
public through a mechanism such as the DNSBL's web site. A DNSBL
s/through a mechanism such as/on / No nonsense please, if it has no
Web site it's anyway bogus.
Availability of documentation concerning a DNSBL SHOULD NOT be
dependent on the continued operation of DNS for the DNSBL zone file.
In other words, if the DNSBL documentation is located at
http://example.com/dnsbl/, the documentation web site SHOULD remain
available even if the DNSBL zone file is not available.
I don't get this, if the list works like 2.0.0.127.example.net, then the
accompanying Web site SHOULD be located at http://example.net Otherwise
the list is bogus and SHOULD NOT be used. Of course it's fine if it has
other URLs for its policy.
With the exception of DNSBLs that that are based on data that does
not change, such as those include the IP addresses associated with
a specific country or geographic region
s/include/listing/ (?)
future. For more aggressive spammers (e.g., those operating their
own ISP) the temporary period MAY be as much as six (6) months.
+ own ISP) the temporary period could be considerably longer (e.g.,
+ weeks) as stated in the listing policy.
I don't get the idea of an arbitrary magic number "6 months". For a
list with say bogon IPs it would be "as long as necessary", unlimited.
You address this later, but IMO no fixed limit also here is clearer.
However, longer periods SHOULD NOT be used since it is possible
that an IP address or domain can change hands, possibly being
allocated to a non-abusive user.
Add "unless it's the stated list policy to cause collateral damage
for users getting their IPs from spam-supporting organizations."
re-checking the IP address security). A re-listing MAY result in
a longer timeout until the listing expires before it is eligible
for removal. Bounded exponential backoff is a good choice for
listing timeout.
ACK, and that upper limit could be worse than six months.
2.2.5. Removals SHOULD Be Possible in Absence of List Administrator.
Removals SHOULD be possible in the absence of the list administrator.
Delete this line.
The recommended approach is to put the DNSBL in its own second
level domain, and then point the DNS NS records for that second
level domain to 127.255.255.255. The TTL for that record should be
set at the maximum allowed period of one week.
Intersting, many DNS details are still a kind of mystery for me, users
would then try to ask a name server at 127.255.255.255, and because
that's a broadcast address on their own LAN they'd get an error, is
that the idea ? Was that concept already tested anywhere ?
"<query>.dnsbl.example.com" rather than "<query>.example.com".
That's what I meant above, http://dnsbl.example.com for the Web site,
and other URLs for the case when the list is terminated. Ideally as
redirection (moved permanently) to the more persistent URL.
The DNSBL MAY list loopback, RFC 1918, LINK-LOCAL class D/E, and
any other permanently reserved or special-use IP addresses.
No, it MUST NOT abuse anything outside of 127.0.0.0/8, and it MUST NOT
abuse 127.0.0.1 (using IPs to signal result codes is IMO abuse, please
limit it as good as you can).
Most DNSBLs follow a convention of entries for IPs in 127.0.0.0/8
Indeed, and anything else is just wrong.
In particular, most DNSBLs use a positive response for 127.0.0.2
s/most/many/ and s/for/of/ You should also mention that lists SHOULD
support 127.0.0.2 as "always listed" test entry, and 127.0.0.1 for the
opposite (never listed), without ever returning 127.0.0.1 as a result.
for this. See reference [DNSBL-EMAIL] for additional information.
Maybe that's not more needed if you explain the trivial concepts here.
[DNSBL-EMAIL] Levine, John; "DNS Based Blacklists and
Whitelists for E-Mail", draft-irtf-asrg-dnsbl-02, November 2005
If you keep RFC 1918 you've to list it as reference. RFC 2119 should
be noted as normative - I think you've somehow lost the section with
normative references.
Nice draft, I like it, thanks,
Frank
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg