At 11:50 10-11-2008, der Mouse wrote:
What the IETF _does_ have a chance to do here is to improve the quality
of a critical piece of Internet infrastructure (email without DNSLs in
today's net is either unusable or very heavily balkanized) by
standardizing those aspects that are in shape to be standardized. The
IETF says "rough consensus and running code". We have the running
code. We even have something close to rough consensus in the field, in
the form of the many DNSL providers and users; I hope the IETF can
recognize that consensus and echo it enough to do what it can to help.
As this document is Standard Track, it's in the IETF
stream. Documents on the Standard track require IETF review and the
consensus of the IETF community. It's not the same as rough
consensus in the field.
Quoting the document:
"This document represents the consensus of the Anti-Spam Research
Group of the Internet Research Task Force."
If this document is published in its current form, I suggest removing
the IRTF Notice.
There is a large user-base for DNSBLs as it's viewed as a cheap
(resource-wise) way to stop spam. Most MTAs have built-in features
to query DNSBLs and reject incoming SMTP connections if the IP
address is listed. Some vendors enable DNSBLs in the default
configuration of the MTA they ship. This has lead to problems over
the years as some DNSBLs were receiving queries even after they were
shut down. Some of them resorted to returning positive responses for
all queries get the attention of the mail administrator as it caused
all mail to be rejected. The document recommends that:
"DNSxL clients SHOULD periodically check appropriate test entries to ensure
that the DNSxLs they are using are still operating."
That would require a change, for the better, in the implementation of
DNSBLs in MTAs. I would go further and suggest that DNSxL clients
should rate limit their queries if the test address does not exist
and must not generate queries to the DNSxL if the test is
unsuccessful after a period of time.
In Section 6:
"A client MUST interpret any returned A record as meaning that an
address or domain is listed in a DNSxL."
There have been cases where a mail server used a DNS server which
returned an A record instead of NXDOMAIN. That can lead to incorrect
results if the above recommendation is followed. It may be better
for the client to validate the returned A record for correctness.
The Security Considerations could have been more exhaustive for a
Standard Track document. For example, if the DNSxLs are
unresponsive, it can affect mail delivery. DNSBLs are
somewhat different from other DNS based services due to their
controversial role. They are generally subject to Denial of Service
and it is worth the emphasis instead of only having a pointer to RFC 3833.
"Since DNSxL users usually make a query for every incoming e-mail
message, the operator of a DNSxL can extract approximate mail volume
statistics from the DNS server logs."
Operators of some types of DNSxLs might also be able to extract some
information about the senders.
As mentioned in the document, name-based DNSBLs are also used to
check the domains found in URLs in message bodies. That can lead to
unintended information disclosure.
Regards,
-sm
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf