Matt Sergeant wrote:
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.
I think we entirely cover that under 2.2.1. Please let us know if
you think we don't.
Yes, I read it top down, and the first definition sounded like "it's
only about 'B' as in 'bl[ao]ck'". Later you have "or anything" with
a 'B' as in 'based'. IP-based geo-location - as far as you believe
in it - can be completely unrelated to 'bl[oa]ck'.
If you want to cover the latter maybe state it earlier, before 2.2.1.
It's certainly a nice example why decisions to block "countries" by
IP could indicate a dangerous degree of ignorance on the side of the
list user. The location could be wrong, it could change any time,
and if users block complete countries they MUST NOT send any abuse
reports to mailboxes in this country while they block the replies.
That's a general principle, if users block something they MUST NOT
send mails to the (from their POV) blackholes, replies won't work.
You could recommend that users blocking IPs should also refuse to
transport messages to the blackhole.
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.
:-) Not sure how we could encode that in a BCP.
How about simply removing (7) and (9) ? Or replace it by a general
advice "try to find and evaluate opinions of third parties about the
list in question". My interpretation of (7) would cover "OPM is for
IRC geeks, therefore it can't be good". And that's wrong. For (9)
I got "read NANAE", but admins should not waste time there, unless
they really like it.
[about "allows a third party to make blocking decisions"]
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".
Not sure which part you think is badly worded here. Please elaborate.
- If a system or network administrator allows a third party to make
- blocking decisions for its network, then the administrator MUST
[...]
+ If a system or network administrator uses the proposals of a third
+ party to make blocking decisions, then the administrator MUST
[...]
s/through a mechanism such as/on/ No nonsense please, if it has
no Web site it's anyway bogus.
It's entirely conceivable that a DNSBL's public presence might be
purely a yahoo-groups mailing list, or NANABL, or some-such.
No, this is not entirely conceivable for a DNSBL with its own zone.
If it can answer queries for 2.0.0.127.dnsbl.example "hosts", then
it can also answer a query for host dnsbl.example, and they can
then arrange that "GET dnsbl.example HTTP/1.0" returns something
useful. If it's a FAQ explaining how to use a YahoGroup or NANABl
it's not ideal, but acceptable as least common denominator.
It's a good convention, it should be recommended. My attempts to
convince Jeff that say http://multi.surbl.org should work, and that
http://surbl.org (without "www" label) should of course also work,
failed. But maybe he'll believe it if you state it as SHOULD... :-)
A low hanging fruit, please don't miss it. It also simplifies the
documentation of tools querying DNSBLs, "... queries x.y.example,
for technical listing details see http://y.example";. If it's not
predictable where a DNSBL has at least a HTTP redirection to its
policy it only makes the maintenance of such tools more difficult.
[upper limit for a listing]
We've mulled over this a lot. Gone back and forth. In the end we
said 6 months because if we put no limit on then it's no help - a
DNSBL could just set the limit at 30 years.
Yes, I'm not very happy with RFCI listings where the evidence is
several years old (of course RFCI is a set of RHSBLs today, no more
DNSBL, and likewise SURBL is no real DNSBL, but most parts of your
draft also work for RHSBLs).
But "6 months" is still an unnecesary magic number. If it's the
stated listing policy to note "postmaster@ bounced 2003-04-01, and
will be listed until they request it in a MAIL FROM postmaster@, and
click on an URL in the reply", then that's as it is, not nice, but
also not unreasonable. Maybe what you really want is that lists
MUST publish the upper limit in their policy (?)
this is very well covered by the last point in this section -
that a temporary listing can easily be extended by (for example)
receiving more spam from this IP/range.
Yes, a second case where reading the I-D bottom up could be better
than top down <gd&r> If you insist on a magic number 6 months is
certainly long enough, maybe already too long.
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."
Even the organisation can change hands. See above.
Caveat emptor. If a tainted IP is worthless, this could be a part
of the "excommunication after XAB" concept. Maybe only RIRs can
clean tainted IPs. Of course users need to know that they're in
for a fundamentalistic armageddon with this approach.
[127.255.255.255]
Was that concept already tested anywhere ?
It has been discussed both here and in many other places.
If the "namedroppers" and similar cabals like it it's fine.
[RFC 1918]
list != result. We're not talking about the result IP here.
Sorry, I got that wrong. If a DNSBL lists private IPs in addition
to the known 127.0.0.2 test entry it should be very clear about it
in its policy. Maybe repeat this as "security consideration", it
could cause havoc. Please add an informative reference to RFC 3330,
it has a nice fresh overview of all special IPv4 addresses. There
ought to be something similar for IPv6, but I don't know where.
In particular, most DNSBLs use a positive response for 127.0.0.2
s/most/many/ and s/for/of/
I think "most" is fine. The second change is correct.
I try to use "combined lists" where possible, limiting the number
of DNS queries, and for combined lists 127.0.0.2 is only one of the
positive responses. Proposed text:
| In particular, DNSBLs use a positive response of 127.0.0.2 or
| other values in the 127.0.0.0/8 range excluding 127.0.0.0/31
| (see RFC 4632 for the notation).
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.
Good point. We'll consider adding that. It's a good test for DNSBL
validity.
Yes, that's the idea. DNS based tools won't directly check q=ns to
catch any 127.255.255.255 condition. Two test queries (127.0.0.2
as listed, 127.0.0.1 as not listed) could detect "osirusoft" stunts.
Or whatever "monkeys" finally did for its formal net suicide.
Frank
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg