On 8-Feb-07, at 7:27 PM, Frank Ellermann wrote:
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.
I think we entirely cover that under 2.2.1. Please let us know if you
think we don't.
7. What are the demographics and quantity of the list's user
base?
How are admins supposed to evaluate this ? Sounds bogus for me.
Certainly easy to lie about, but a BCP doesn't cover lying. It could
certainly be stated on the DNSBL's web page, or could be stated on a
separate page on whichdnsbl.com (yes, I made that up, though it is
available!).
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.
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".
Not sure which part you think is badly worded here. Please elaborate.
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.
Possibly, but that is not the intention, and is not something we
could BCP about IMHO. If a private entity wishes to follow these
ideas then that's fantastic, but not what this BCP is about.
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.
I think this is just draft preamble, required for discussion here.
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.
It's entirely conceivable that a DNSBL's public presence might be
purely a yahoo-groups mailing list, or NANABL, or some-such. With
FAQs and listing criteria regularly published to such locations.
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.
There are major problems with this. What if you decide to stop
running the DNSBL? See section 3.2. I see no reason to remove this
section.
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/ (?)
Good catch. Thank you.
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.
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. 6 months is reasonable for a
long listing, and 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.
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.
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.
Yup.
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 ?
It has been discussed both here and in many other places.
"<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.
Not sure what you mean here. Hopefully you're agreeing with what I
said above.
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).
list != result. We're not talking about the result IP here. Just what
can be present in the DNSBL.
Most DNSBLs follow a convention of entries for IPs in 127.0.0.0/8
Indeed, and anything else is just wrong.
Possibly/probably yeah. But this BCP doesn't cover that.
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.
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.
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,
Thanks for your comments. Very useful.
Matt.
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg