Keith Moore wrote: > Dave CROCKER wrote: > >> The difficulty is that the current line of argument is that because some >> DNSBLs are operated badly, DNSBLs are bad. > > I have a strong suspicion that poor design of the DNSBL protocol (and/or > its interface to SMTP and NDNs) encourages more badness than is needed. Step back from DNSBLs. What you are describing is more properly a BCP for the implementation of email filters in general, and is not directly relevant to the protocols involved in any one kind of filtering. These are NOT reputation systems issues. These are filter implementation issues. The problems you ascribe below are equally (or more) applicable to almost all other filtering techniques - whether or not you're relying on external supplied filtering information. The ones that this isn't applicable (such as greylisting, or banner delays for example), are often by their very nature incompatible with your suggestions (eg: you can't quarantine a banner delay FP). As such, such considerations really belong in a entirely different document about filtering in general. Which is a fine charter for a WG, more useful than one on DNSBLs or reputation systems specifically. So, I'm going to attempt to cover your "for instance" from a more general perspective - showing that your "for instance" scenarios are already broadly implemented throughout the industry, but there are problems and caveats that you're not aware of. > For instance, what would happen if mail servers provided feedback to > both senders (on a per message basis in the form of NDNs) They already provide feed back to senders. Most filtering systems supply NDNs with either a reasonably direct explanation of what happened (eg: "we don't allow swear words", or "see http://spamhaus.org/lookup=X";), or provide means by which remediation can be achieved, eg: "If you believe this is in error, please contact filtops@xxxxxxxxxx with the following sessionid ....". [That's what ours says.] DNSBLs are perhaps the best at supplying suggested text for the NDN (eg: TXT records in the protocol spec.). Other systems aren't so consistent. But remember, it's only a suggestion. The filter implementer need not use it. We don't. On purpose. We have chosen, as a corporate, to not reveal _any_ filtering reasons in NDNs as a security measure, and get the sender to contact us for remediation (via the message I quoted above), and explanation if necessary for remediation. Any BCP that insists on the NDNs being perfectly transparent about "why this email was blocked" is going to be rejected by a large chunk of the industry, DNSBLs or otherwise. You want to know how to get the email blockage fixed. That's a different question than "why was this was blocked". If you can satisfy the former, the latter is seldom necessary. > and recipients > (say, via a web page that listed messages blocked due to DNSBLs)... Many systems, particularly the large ones (eg: all outsourced spam filtering systems, all very large ISP environments etc) provide recipients with one way or another to examine "filtered email", either by tagging, junk folder, web-based quarantine, or summary email notifications - we do the latter two. > in > both cases describing which DNSBL blocked the message and what the > blocking criteria were? Many systems provide direct explanations of the reasons for why the email is in the quarantine or junk folders. Probably becomes "Most" if the user knows how to look. We've explicitly chosen to inhibit displaying the "reason" to the recipient for a particular block for three reasons - security (see above), useability (most users would have difficulty figuring out how to apply the information, so we do it for them), and finally, see below: > What if recipients could disable blocking on a per-DNSBL basis? They often can. Many server-based systems implement per-user customization. However, experience seems to indicate that such functionality is almost never used, and when it is, it's almost always a "all filters on" or "all filters off" choice. Secondly, as a corporate entity (rather than a service provider), it's our email flow, and our ultimate responsibility and liability about what happens on it. In fact, legislation _requires_ us to filter certain things. Therefore, you can't opt out of our filters without a formal security exemption. A BCP requiring per-user opt-out won't be acceptable to the industry. > Assuming that we're going to have reputation services, I'm looking for > ways to make them more accountable/responsible. Your suggestions can't be implemented by a reputation service. Only the filter implementor can, and these suggestions apply equally to all filtering techniques. Doesn't belong in a DNSBL protocol specification. _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf