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(_at_)nortel(_dot_)com 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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf