Chris Lewis <clewis(_at_)nortel(_dot_)com> wrote:
... This is why I, Matt Sergeant, and others have been working on
a DNSBL policy BCP what could be considered a companion document:
http://www.ietf.org/internet-drafts/draft-irtf-asrg-bcp-blacklists-04.txt
I hope to make a few final grammatical changes to the above document in
the next few days and move it on towards last call.
First, a meta-comment:
I hope we don't try to make a class of documents called IRTF BCPs.
The intent behind this, I hope, is to work on it in IRTF's ASRG, then
submit it to the IESG as an Individual Sumbission.
I don't think that's a good idea either; but I can't criticize it
if the IESG intends to discourage AppsAREA WGs dealing with spam issues,
as at least one previous IESG has done.
] Abstract
] The rise of spam and other anti-social behavior on the Internet has
] led to the creation of shared DNS-based lists ("DNSBLs") of IP
] addresses or domain names intended to help guide email filtering.
] This memo discusses guidelines for the management of public DNSBLs by
] their operators as well as for the proper use of such lists by mail
] server administrators (DNSBL users), and it provides useful
] background for both parties. It is not intended to advise on the
] utility or efficacy of particular DNSBLs or the DNSBL concept in
] general, nor to assist end users with questions about spam.
This is reasonably clearly stated. Whether there is any sort of IETF
consensus about the existence of "proper" use seems to be in question.
Much of the document actually describes the history of "DNSBLs", which
I would hope most of us would be happy to see in an Informational RFC.
] 1.1. DNS-Based Reputation Systems
]...
] This document is intended to provide guidance to DNSBL operators so
] that they may be able to identify what features users would be
] interested in seeing as part of a high-quality, well-managed DNSBL,
I'm not sure this is a reasonable goal for any IETF document.
Predicting what users will want in the future is extremely iffy.
(Even predicting the present is beyond _my_ ability!)
] 1.2. Guidance for DNSBL Users
]...
] The DNSBL user MUST ensure that they understand the intended use of
] the DNSBL.
This doesn't feel like a 2119 MUST. While it _is_ arguably abuse
of a DNSBL, there will inevitably be cases like SpamAssassin where
DNSBLs are used in scoring at a level where it doesn't make sense
for the receiving MTA's administrator to understand any details of
the "intended use".
] 2.1. Transparency
]...
] A DNSBL MUST abide by its stated listing and delisting criteria.
This is a better fit to a 2119 MUST, but frankly I don't think we
should encourage DNSBL users to depend on it.
] 2.2.1. Listings SHOULD Be Temporary
]...
] It is RECOMMENDED that DNSBL operators publish in general terms their
] expiration policy is, even if its only "delist on request" or no
] expiration is performed.
An absolutely reasonable principle, stated absolutely correctly.
] 2.2.2. A Direct Non-Public Way to Request Removal SHOULD Be Available
]...
] The DNSBL operator MUST NOT use the list in question in such a way
] that removal requests would be blocked,
A correct 2119 MUST-NOT...
] and, moreover, SHOULD make mailboxes available in order to allow
] affected users to submit their requests.
This may not be reasonable. A publicly-known email address can too
easily be DoS'd. A more useful statement, IMHO, would be that any
email-based mechanism for submission of removal requests SHOULD promptly
and clearly indicate whether the request is queued for action on the
request.
====
There's a lot of good work that went into this document, and I don't
mean to speak against its publication. But it seems to me to be a poor
fit to the IRTF, and I'd be much happier to see this sort of work in
an IETF WG. Writing such a document to avoid becoming quickly outdated
strikes me as an impossible task; and the "right" approach would be to
design services that could avoid the many pitfalls we are seeing with
the current usage of DNSBLs.
--
John Leslie <john(_at_)jlc(_dot_)net>
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf