Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
In message <[EMAIL PROTECTED]>, Florian Weimer writes: > * Mark Andrews: > > > In message <[EMAIL PROTECTED]>, Florian Weimer writes: > >> * Stephane Bortzmeyer: > >> > >> > Second question, the document indeed standardizes many things which > >> > are not in common use but does not point towards a rationale, so some > >> > choices are puzzling. Why TXT records to point to an URL and not > >> > NAPTR? Is this because of current usage in DNSxL? If so, this should > >> > be noted. But why IPv6 lists use a A record and not a ? I am not > >> > aware of existing IPv6 lists so this cannot be the current usage? > >> > >> The lack of a macro capability also means that it's basically > >> impossible to secure DNSBL zones with DNSSEC when they contain larger > >> chunks of address space; see the example in section 2.1. > > > > How so? > > The expectation is that error messages generated from TXT records > contain the actual IP addresses which triggered the DNSBL lookups. As > a result, if you list a /16 (say), you need publish 65,536 different > TXT records. > > Currently, these records are synthesized using a macro capability in > the DNS server. Which is independent of DNSSEC. I ask again how this a DNSSEC problem. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
In message <[EMAIL PROTECTED]>, Florian Weimer writes: > * Mark Andrews: > > >> >> The lack of a macro capability also means that it's basically > >> >> impossible to secure DNSBL zones with DNSSEC when they contain larger > >> >> chunks of address space; see the example in section 2.1. > >> > > >> > How so? > >> > >> The expectation is that error messages generated from TXT records > >> contain the actual IP addresses which triggered the DNSBL lookups. As > >> a result, if you list a /16 (say), you need publish 65,536 different > >> TXT records. > >> > >> Currently, these records are synthesized using a macro capability in > >> the DNS server. > > > > Which is independent of DNSSEC. I ask again how this a > > DNSSEC problem. > > I didn't say it was a DNSSEC problem. I just wanted to note it's > impossible to secure some existing DNSBL zones using DNSSEC without > sacrificing some of the functionality which is mentioned in section > 2.1 in the draft. I still don't believe your claim. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
Florian Weimer wrote: > I can't sign a thousand million RRsets and serve it in a DoS-resilient > manner, even with John's partitioning idea (which is rather neat, > thanks!). I may have to keep that in mind if I ever DNSSEC our internal composite DNSBL zone, which has probably near 500M IPs listed (both "bad" and "good"). [The zone file is > 500Mbytes] > Macro expansion in the client brings down the number of RRsets to a > challenging, but manageable level. Chris says there's precedent for > that, so I think we can end this subthread (or move the discussion to > some place where the topic of DNSSEC scalability would be more > on-topic). Even more for a client-supplied string being macro-expanded in the client. Eg: no TXT query at all. If I had to guess, I suspect that more than half of clients don't issue a TXT query and synthesize their own error message instead. The vast majority of DNSBLs are arranged so that a single message with macro substitution of IP is sufficient to produce a useful error message, so why wait for a TXT query if you can configure the client to generate its own? Even tho I publish TXT records in our internal DNSBL zone, the filters themselves don't query them. The TXT records are used by administrative tools as part of the FP process because they contain diagnostic information on the entries. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
* Mark Andrews: >> I didn't say it was a DNSSEC problem. I just wanted to note it's >> impossible to secure some existing DNSBL zones using DNSSEC without >> sacrificing some of the functionality which is mentioned in section >> 2.1 in the draft. > > I still don't believe your claim. I can't sign a thousand million RRsets and serve it in a DoS-resilient manner, even with John's partitioning idea (which is rather neat, thanks!). Macro expansion in the client brings down the number of RRsets to a challenging, but manageable level. Chris says there's precedent for that, so I think we can end this subthread (or move the discussion to some place where the topic of DNSSEC scalability would be more on-topic). ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
* Chris Lewis: > Florian Weimer wrote: > >> The expectation is that error messages generated from TXT records >> contain the actual IP addresses which triggered the DNSBL lookups. As >> a result, if you list a /16 (say), you need publish 65,536 different >> TXT records. >> >> Currently, these records are synthesized using a macro capability in >> the DNS server. > > How does that break DNSSEC? You'd need online signature generation (which implies sharing the key with all mirrors), or hundreds of millions of precomputed signatures for some existing zones. (Due to the prevalent attack scenario, more frequent than usual key rollovers are needed, so this really hurts.) > A number of DNSBLs merely suggest an error message in their usage > instructions, and leave it up to the client to synthesize a > combination of the suggested error message and the IP address. > Macro expansion in the client (either of supplied TXT or > client-configured string) seems common. I've been told that this approach would not be acceptable. But my source probably lacked your insight into the field. With macro expansion in the client, signing and serving typical DNSBLs is still somewhat of a challenge, but doable. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
>The expectation is that error messages generated from TXT records >contain the actual IP addresses which triggered the DNSBL lookups. As >a result, if you list a /16 (say), you need publish 65,536 different >TXT records. Some do, some don't. In any event I agree that DNSSEC is not ideally suited to signing DNSBLs, but I would think that with some judicious partitioning into subzones the problem wouldn't be intractable. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
* Mark Andrews: >> >> The lack of a macro capability also means that it's basically >> >> impossible to secure DNSBL zones with DNSSEC when they contain larger >> >> chunks of address space; see the example in section 2.1. >> > >> >How so? >> >> The expectation is that error messages generated from TXT records >> contain the actual IP addresses which triggered the DNSBL lookups. As >> a result, if you list a /16 (say), you need publish 65,536 different >> TXT records. >> >> Currently, these records are synthesized using a macro capability in >> the DNS server. > > Which is independent of DNSSEC. I ask again how this a > DNSSEC problem. I didn't say it was a DNSSEC problem. I just wanted to note it's impossible to secure some existing DNSBL zones using DNSSEC without sacrificing some of the functionality which is mentioned in section 2.1 in the draft. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
Florian Weimer wrote: > The expectation is that error messages generated from TXT records > contain the actual IP addresses which triggered the DNSBL lookups. As > a result, if you list a /16 (say), you need publish 65,536 different > TXT records. > > Currently, these records are synthesized using a macro capability in > the DNS server. How does that break DNSSEC? A number of DNSBLs merely suggest an error message in their usage instructions, and leave it up to the client to synthesize a combination of the suggested error message and the IP address. Macro expansion in the client (either of supplied TXT or client-configured string) seems common. Of course, they're still only suggestions, and some DNSBL users will generate their own. The worst of all is the clients that don't tell you what the IP was and no other way to remediate issues. There are situations like this which even leave admins scratching their heads. [While the BCP isn't yet on the table w.r.t. the spec (it may be), this issue is covered in the BCP.] ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
* Mark Andrews: > In message <[EMAIL PROTECTED]>, Florian Weimer writes: >> * Stephane Bortzmeyer: >> >> > Second question, the document indeed standardizes many things which >> > are not in common use but does not point towards a rationale, so some >> > choices are puzzling. Why TXT records to point to an URL and not >> > NAPTR? Is this because of current usage in DNSxL? If so, this should >> > be noted. But why IPv6 lists use a A record and not a ? I am not >> > aware of existing IPv6 lists so this cannot be the current usage? >> >> The lack of a macro capability also means that it's basically >> impossible to secure DNSBL zones with DNSSEC when they contain larger >> chunks of address space; see the example in section 2.1. > > How so? The expectation is that error messages generated from TXT records contain the actual IP addresses which triggered the DNSBL lookups. As a result, if you list a /16 (say), you need publish 65,536 different TXT records. Currently, these records are synthesized using a macro capability in the DNS server. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
In message <[EMAIL PROTECTED]>, Florian Weimer writes: > * Stephane Bortzmeyer: > > > Second question, the document indeed standardizes many things which > > are not in common use but does not point towards a rationale, so some > > choices are puzzling. Why TXT records to point to an URL and not > > NAPTR? Is this because of current usage in DNSxL? If so, this should > > be noted. But why IPv6 lists use a A record and not a ? I am not > > aware of existing IPv6 lists so this cannot be the current usage? > > The lack of a macro capability also means that it's basically > impossible to secure DNSBL zones with DNSSEC when they contain larger > chunks of address space; see the example in section 2.1. How so? -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
* Stephane Bortzmeyer: > Second question, the document indeed standardizes many things which > are not in common use but does not point towards a rationale, so some > choices are puzzling. Why TXT records to point to an URL and not > NAPTR? Is this because of current usage in DNSxL? If so, this should > be noted. But why IPv6 lists use a A record and not a ? I am not > aware of existing IPv6 lists so this cannot be the current usage? The lack of a macro capability also means that it's basically impossible to secure DNSBL zones with DNSSEC when they contain larger chunks of address space; see the example in section 2.1. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
On Nov 10, 2008, at 7:18 AM, Keith Moore wrote: John Levine wrote: As I said a few messages up in this string, although the structure of IPv4 DNSxLs has long since been cast in concrete, IPv6 DNSxLs aren't that mature yet and one of my goals was to make them interoperate equally well so, for example, if you find you're using cruddy ones you can easily switch to better ones. I suspect it will be very difficult to make IPv6 DNSxLs work anywhere nearly as well as IPv4 DNSxLs, because in IPv6 it is fairly easy to use a different address for every SMTP conversation. Agreed. One might hope that the future will use DKIM domains and "on- behalf-of" tuples as an alternative to that of an IP address blocking list. Ideally, the "on-behalf-of" would be an opaque value assigned by the provider, that is changed whenever a problem is corrected. This would eliminate the need for coordination between those that run reputation services and the senders. Those that abuse this freedom would be at risk of finding their entire domain blocked instead. The problem that needs solved is how to block compromised systems, more than blocking individuals. Frankly, it would be best not to have any personably identifiable values used. Unfortunately, being able to detect misbehavior at a sufficient level to safely conclude whether an outbound MTA is poorly managed requires rather extensive infrastructure. This infrastructure is often several times larger than the typical infrastructure of a client being protected. These services address the problem of scaling email defenses. Assessments are fairly difficult when the MTA being judged has little volume, since even an occasional misidentification of NDN as spam might create a profile fairly similar to those created by bot- nets. Bot-nets represent a sizable portion of today's spam sources. IMHO, the goal of the black-hole list should be to inform ISPs and have them remove bad actors from their network and hopefully to encourage them to better monitor their own traffic. ISPs will not agree with this. Even the largest decoy infrastructure sees only a tiny fraction of the overall traffic. A desire to rapidly block any IP address that appears to be actively spamming provides bad actors a simple way to locate decoys and render the system less effective. While there are ways to deal with this problem, it both increases the infrastructure required, and the duration of a listing applied to problematic addresses. While there may be some concern that DNSxLs use A records as a flag, normally these records are limited to an address range of 127.255.255.255 - 127.0.0.2 (only 23 bits worth of data). It seems unlikely that the use of these IP addresses will lead to any problem. The reason for suggesting that the document be published as Informational has to do with there not being _any_ real experience yet in attempting to block IPv6 addresses. Routers will only be handling a faction of the total IP address space that IPv6 makes available. IPv6 DNSxL entries will not represent the same number of routes managed by routers. This would suggest that entire networks are to be blocked whenever a significant level of abuse is detected that warrants blocking. This would be a rather bunt tool. There are a few points that this draft attempts to answer in a reasonable way. The software used by the DNS servers is not going to change to support the IPv6 address space. The servers will continue in the same fashion as before. Instead of a query address of 127.0.0.2, this draft suggest the value :::7F00:2 to test the existence of the list. Until there is some greater experience in handling IPv6 address space, do not get ahead of the problem by concluding how this service is to resolve the practical challenges ahead. When a network handles a mixture of legitimate and abusive traffic, it may be impossible to cope with the volume of tracking data that will be required. After all, evidence MUST BE retained for everything blocked to squelch erroneous customer complaints and the occasional law suit threat. While SANs are getting bigger, to scale these systems for tracking addresses within an IPv6 network is unlikely to be economically all that practical. This might be wrong, but it should be less expensive for reputation services to use DKIM domains and an opaque "on-behalf- of" value instead. DKIM would also create less danger with respect to collateral blocking. MTAs may need to be equipped with crypto hardware to deal with foo signature abuse. At least MTAs should be able to rate limit any IP address sending foo signatures. -Doug ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: IPv6 traffic stats (was: Re: Last Call: draft-irtf-asrg-dnsbl(DNS Blacklists and Whitelists))
Who cares about the use measurement? I care about the proportion of the Internet where I can obtain acceptable service with full functionality via an IPv6-only endpoint connection. From: [EMAIL PROTECTED] on behalf of David Kessens Sent: Wed 11/12/2008 4:28 PM To: Joe St Sauver Cc: ietf@ietf.org Subject: Re: IPv6 traffic stats (was: Re: Last Call: draft-irtf-asrg-dnsbl(DNS Blacklists and Whitelists)) Joe, On Tue, Nov 11, 2008 at 03:12:53PM -0800, Joe St Sauver wrote: > David mentioned: > > On the other hand, just to put this in context and to pick on an > application I'm somewhat familiar with, a single full-ish Usenet news > feed is now in excess of 3TByte/day (see the daily volume stats quoted > at http://en.wikipedia.org/wiki/Usenet ). Just two or three full-ish > Usenet News feeds over IPv6, if done across AMS-IX, would account > for most of that 800Mbps traffic load (assuming that Usenet is what > was making up most of that traffic, an assertion that I'm explictly > NOT making). My point? It is possible that the IP transport choices > of just a few cooperating server administrators might (at least > hypothetically) account for virtually all the observed growth in > AMS-IX IPv6 traffic. Very good analysis: rumor has it that a large part of the AMS-IX traffic is indeed usenet traffic. However, that doesn't mean that it is not real IPv6 traffic: eg. we don't decide not to count IPv4 Usenet traffic either. On the other hand, this graph only shows native traffic so there is most likely more than what is visible in the graph. However, there are quite a few other observations by others (also mentioned on this list) that put the total amount of IPv6 traffic to various other parts of the Internet at a bit more but in the same order of magnitude so it doesn't seem that the AMS-IX data is out of line (various presentations on this topic from the last RIPE meeting are available on rosie.ripe.net, look for ipv6 working group or plenary). > So to bring this post to a close, I continue to believe that IPv6 > traffic, at least IPv6 email traffic, remains very, very low, to > the point where, as I've previous mentioned, it just hasn't justified > DNS block list operator attention in any material way (love to hear > about any counter examples, BTW). This of course depends a bit on what you define as very, very low. However, I can certainly see that it is not enough to get the attention of a DNS block list operator. I do do know however, that I received my first spam mail over IPv6 several years ago. The reason for my mail was not to disproof your point but to put the arbornetworks numbers in a bit more perspective. David Kessens --- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 traffic stats (was: Re: Last Call: draft-irtf-asrg-dnsbl(DNS Blacklists and Whitelists))
"Danny McPherson" <[EMAIL PROTECTED]> wrote: > To be clear, our attempt with this study was to measure > observable IPv6 traffic in production networks across a > large number of production ISP networks. It was not to > discredit IPv6 in any way, quite the contrary. That's great and it will be even better when this study is repeated in a few months using the same data set and methodology. This way, you can start tracking growth. Comparing this set of results with other sets obtained using different methodologies & data sets would be like comparing apples and oranges. Warm regards, Olivier -- Olivier MJ Crepin-Leblond, Ph.D Global Information Highway Ltd http://www.gih.com/ocl.html ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 traffic stats (was: Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists))
Danny, On Wed, Nov 12, 2008 at 06:11:11PM -0700, Danny McPherson wrote: > > I look forward to any credible data that you can provide > to support wider adoption, or being made aware of any > unacknowledged issues with our methodology. As I mentioned in another mail to the ietf list today: various presentations on this topic from the last RIPE meeting are available on rosie.ripe.net, look for ipv6 working group or plenary David Kessens --- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 traffic stats (was: Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists))
On Nov 12, The report as presented at the RIPE meeting indeed mentions the possibility of undercounting. However, it appears that there is an undercount of several orders of magnitude. At that point you really cannot claim that the report provides a perspective on Internet IPv6 traffic as it does. It is quite reasonable to conclude that something went wrong with the methodology, measurements or analysis. Nothing is wrong in the methodology and the places where undercounting likely occurred (namely: flow types supported by exporting routers, Teredo data channels, etc..) have been identified. Caveat-aware, I believe the report to be both very quantitive and qualitative. Furthermore, what we measured is what the ISPs involve have visibility to, which is a critical consideration - if you can't see it, and can't measure it, then you certainly can't qualify it. If you have any more *quantitative* and qualitative studies that you can point to I and many others would be quite interested. The difference between something that is barely measurable and something small but measurable like 0.1% is huge. Basically, 0.1% on the scale of the Internet means that a very large group of people is using IPv6 today. There is no question that that group pales to the total number of Internet users but it sure is more than a few people in IETF experimenting with IPv6. That's great news, and I look forwarding to seeing more data from this large group of people... To be clear, our attempt with this study was to measure observable IPv6 traffic in production networks across a large number of production ISP networks. It was not to discredit IPv6 in any way, quite the contrary. I look forward to any credible data that you can provide to support wider adoption, or being made aware of any unacknowledged issues with our methodology. -danny ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 traffic stats (was: Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists))
Joe, On Tue, Nov 11, 2008 at 03:12:53PM -0800, Joe St Sauver wrote: > David mentioned: > > On the other hand, just to put this in context and to pick on an > application I'm somewhat familiar with, a single full-ish Usenet news > feed is now in excess of 3TByte/day (see the daily volume stats quoted > at http://en.wikipedia.org/wiki/Usenet ). Just two or three full-ish > Usenet News feeds over IPv6, if done across AMS-IX, would account > for most of that 800Mbps traffic load (assuming that Usenet is what > was making up most of that traffic, an assertion that I'm explictly > NOT making). My point? It is possible that the IP transport choices > of just a few cooperating server administrators might (at least > hypothetically) account for virtually all the observed growth in > AMS-IX IPv6 traffic. Very good analysis: rumor has it that a large part of the AMS-IX traffic is indeed usenet traffic. However, that doesn't mean that it is not real IPv6 traffic: eg. we don't decide not to count IPv4 Usenet traffic either. On the other hand, this graph only shows native traffic so there is most likely more than what is visible in the graph. However, there are quite a few other observations by others (also mentioned on this list) that put the total amount of IPv6 traffic to various other parts of the Internet at a bit more but in the same order of magnitude so it doesn't seem that the AMS-IX data is out of line (various presentations on this topic from the last RIPE meeting are available on rosie.ripe.net, look for ipv6 working group or plenary). > So to bring this post to a close, I continue to believe that IPv6 > traffic, at least IPv6 email traffic, remains very, very low, to > the point where, as I've previous mentioned, it just hasn't justified > DNS block list operator attention in any material way (love to hear > about any counter examples, BTW). This of course depends a bit on what you define as very, very low. However, I can certainly see that it is not enough to get the attention of a DNS block list operator. I do do know however, that I received my first spam mail over IPv6 several years ago. The reason for my mail was not to disproof your point but to put the arbornetworks numbers in a bit more perspective. David Kessens --- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 traffic stats (was: Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists))
Danny, On Wed, Nov 12, 2008 at 01:15:07PM -0700, Danny McPherson wrote: > > On Nov 11, 2008, at 11:57 AM, David Kessens wrote: >> >> It seems that arbornetworks estimates are extremely low to the point >> where one has to ask whether there were other issues that caused such >> a low estimate. > > No, the methodology is outlined in the referenced report. > Given what we were measures and what data was supplied, those > were the results. The report as presented at the RIPE meeting indeed mentions the possibility of undercounting. However, it appears that there is an undercount of several orders of magnitude. At that point you really cannot claim that the report provides a perspective on Internet IPv6 traffic as it does. It is quite reasonable to conclude that something went wrong with the methodology, measurements or analysis. >> There is no question that IPv6 traffic is quite low in the Internet. >> However, many other reports that I have seen recently measure multiple >> orders of magnitude more IPv6 traffic (for an easily accesible example >> see: http://www.ams-ix.net/technical/stats/sflow/) > > Indeed, and multiple orders (less than two) of magnitude is still, > from this, only .1% on average. I believe the point remains very > much the same. The difference between something that is barely measurable and something small but measurable like 0.1% is huge. Basically, 0.1% on the scale of the Internet means that a very large group of people is using IPv6 today. There is no question that that group pales to the total number of Internet users but it sure is more than a few people in IETF experimenting with IPv6. David Kessens --- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 traffic stats (was: Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists))
On Nov 11, 2008, at 11:57 AM, David Kessens wrote: Joe, On Tue, Nov 11, 2008 at 08:20:11AM -0800, Joe St Sauver wrote: I'm not aware of DNS block lists which cover IPv6 address spaces at this time, probably in part because IPv6 traffic remains de minimis (see http://asert.arbornetworks.com/2008/8/the-end-is-near-but-is-ipv6/ showing IPv6 traffic as constituting only 0.002% of all Internet traffic). For the record: It seems that arbornetworks estimates are extremely low to the point where one has to ask whether there were other issues that caused such a low estimate. No, the methodology is outlined in the referenced report. Given what we were measures and what data was supplied, those were the results. There is no question that IPv6 traffic is quite low in the Internet. However, many other reports that I have seen recently measure multiple orders of magnitude more IPv6 traffic (for an easily accesible example see: http://www.ams-ix.net/technical/stats/sflow/) Indeed, and multiple orders (less than two) of magnitude is still, from this, only .1% on average. I believe the point remains very much the same. -danny ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
On Wed, 12 Nov 2008, Andrew Sullivan wrote: > On Wed, Nov 12, 2008 at 05:23:12PM +, Tony Finch wrote: > > On Tue, 11 Nov 2008, Andrew Sullivan wrote: > > > > > > In addition, the document proposes to continue using the existing > > > mechanism in order to support IPv6 hosts. There is little evidence of > > > a widespread deployment of such use, > > > > Exim has had support for IPv6 DNS lists as described by this draft for > > many years. > > I fail completely to see how that is even a little bit evidence that > there is widespread deployment of IPv6 mail hosts, use of them, or > anything of the sort. Sorry, I thought you were referring to deployment of the DNSxL protocol that the draft documents. Tony. -- f.anthony.n.finch <[EMAIL PROTECTED]> http://dotat.at/ SOUTHEAST ICELAND: SOUTHEASTERLY VEERING SOUTHWESTERLY 4 OR 5, INCREASING 6 AT TIMES, VEERING NORTHERLY 5 TO 7 LATER. MODERATE OR ROUGH. OCCASIONAL RAIN. MODERATE OR GOOD, OCCASIONALLY POOR. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
On Wed, Nov 12, 2008 at 05:23:12PM +, Tony Finch wrote: > On Tue, 11 Nov 2008, Andrew Sullivan wrote: > > > > In addition, the document proposes to continue using the existing > > mechanism in order to support IPv6 hosts. There is little evidence of > > a widespread deployment of such use, > > Exim has had support for IPv6 DNS lists as described by this draft for > many years. I fail completely to see how that is even a little bit evidence that there is widespread deployment of IPv6 mail hosts, use of them, or anything of the sort. I gather our point wasn't clear enough, though, so I'll try to make it clearer. The point is that we do not have today a large installed base of IPv6-native networks interoperating, with large-scale spam problems that need urgent attention, in the way that we have those problems on IPv4-hosted mail infrastructure. I am aware that there is some IPv6 deployment, and I am aware that in those environments there are of course mail servers. But deployment is nowhere near the scale of the deployed v4 architecture. Therefore, we have an opportunity now, before v6 is everywhere, to do something about the deployed code. That isn't to say there will not need to be some backward-compatibility efforts (which you may pronounce "kludges" if your local policy permits). I think we said that in our original message, however. Best regards, Andrew -- Andrew Sullivan [EMAIL PROTECTED] Shinkuro, Inc. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
On Tue, 11 Nov 2008, Andrew Sullivan wrote: > > In addition, the document proposes to continue using the existing > mechanism in order to support IPv6 hosts. There is little evidence of > a widespread deployment of such use, Exim has had support for IPv6 DNS lists as described by this draft for many years. Tony. -- f.anthony.n.finch <[EMAIL PROTECTED]> http://dotat.at/ SOUTHEAST ICELAND: SOUTHEASTERLY 5 OR 6, VEERING SOUTHWESTERLY 4 OR 5 LATER. MODERATE OR ROUGH. OCCASIONAL RAIN. MODERATE OR GOOD, OCCASIONALLY POOR LATER. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
Dear colleagues, We have read draft-irtf-asrg-dnsbl-07. We have some comments on the draft in response to the last call. We wish to emphasise that, while we currently serve as the co-chairs of the DNS Extensions working group, these comments are merely our own, and are not representative of the views of the working group. We believe we understand the purpose of DNSxLs, and we think they can, in some circumstances, provide a useful service (even though they sometimes cause difficulty for users of Internet mail). We also think that describing current behaviour of DNSxLs is a good thing. That said, we are uncomfortable with the draft in its current form, and are strongly opposed to adopting it as a Proposed Standard. We believe that most, but not all, of the draft would be an excellent candidate for adoption as an Informational document. One problem with the document is its outline of the way that DNSxLs use A records to indicate reasons to accept or reject traffic from a given site. The trouble is that these A records are not host addresses, even though that's the definition of an A record. The A records merely _look_ like host addresses. In order to understand that they are not host addresses, you have to know what DNS server you are querying and interpret the owner name at the record. What this really does is use the context of the query, plus the content of the query and answer, as meta-data in order to add new semantics to A records: if you happen to query server dnsbl.example.org with just the right owner name, you get an A record that is not a host address. Note that merely knowing the DNS server name is not enough: the document points out that if you query the same server with a different owner name, you might get an A record that _is_ a host address. In addition, the context of the answer determines its use: the same server can use the same zone data to provide whitelist and blacklist services to two different groups of querying agents. Now, it is surely a service to the Internet community to document that there are DNS servers where the content of the answer determines the semantics of the record, but we don't really think this is something that we should plan to advance on the standards track. It seems plain to us that the reason DNS has RRTYPEs is so that the client doesn't need to guess what kind of record it has when it gets a resource record. In our view, the document really needs to make clear that DNSxLs are violating the semantics of A records when they make this use of them. One way to do that would be to modify the first paragraph in section 2 along the following lines: A DNSxL is a zone in the DNS[RFC1034][RFC1035]. The zone containing resource records identifies hosts present in a blacklist or whitelist. Hosts were originally encoded into DNSxL zones using a transformation of their IP addresses, but now host names are sometimes encoded as well. Most DNSxLs still use IP addresses. The zone accepts and responds to DNS queries in apparently standard ways. The zone data, however, is not DNS data, and has special semantics that can be understood only in the context of the DNSxL service. In particular, A records returned by the server usually do not contain a host address. Instead, they usually contain a 32 bit value to be interpreted as bitfields. For historical reasons, implementations used the DNS A RRTYPE to represent these values, rather than a distinct RRTYPE. As noted in section 5, some A records in a DNSxL zone MAY contain host records. How clients interpret different A records in the same DNSxL zone is implementation- and context-dependent. In addition, the document proposes to continue using the existing mechanism in order to support IPv6 hosts. There is little evidence of a widespread deployment of such use, and there is therefore still time to come up with a better solution that does not overload the meaning of RRTYPEs before we have widespread use of IPv6 mail infrastructure. Therefore, in our opinion, extending the current practice to IPv6 hosts is not a good idea. The current draft makes the best of a bad principle, but it should recommend an alternative approach as preferable. One simple solution would be to introduce one or, better, two new RRTYPE(s) that work(s) exactly the same way as the A RRTYPE, so that deployed software would need to be modified only to query for the new RRTYPE instead of an A record. We appreciate that a long, or maybe indefinite, transition period would be needed. Presumably, however, the widespread introduction of IPv6 in the mail infrastructure of organisations will occasion the installation of new software as well. Best regards, Olafur Gudmundsson [EMAIL PROTECTED] Andrew Sullivan [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: IPv6 traffic stats (was: Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists))
David mentioned: #For the record: # #It seems that arbornetworks estimates are extremely low to the point #where one has to ask whether there were other issues that caused such #a low estimate. # #There is no question that IPv6 traffic is quite low in the Internet. #However, many other reports that I have seen recently measure multiple #orders of magnitude more IPv6 traffic (for an easily accesible example #see: http://www.ams-ix.net/technical/stats/sflow/) The Ether Type graph on the AMS-IX page indicates that IPv6 is on average 1/10th of 1% all the traffic they measure, and looking at the associated RRDtool graphs, that works out to be ~800Mbits/second. A sustained ~800 Mbits/second is certainly nothing to sneeze at, and everyone who has worked hard to encourage IPv6 deployment deserves many kudos. Progress is happening! On the other hand, just to put this in context and to pick on an application I'm somewhat familiar with, a single full-ish Usenet news feed is now in excess of 3TByte/day (see the daily volume stats quoted at http://en.wikipedia.org/wiki/Usenet ). Just two or three full-ish Usenet News feeds over IPv6, if done across AMS-IX, would account for most of that 800Mbps traffic load (assuming that Usenet is what was making up most of that traffic, an assertion that I'm explictly NOT making). My point? It is possible that the IP transport choices of just a few cooperating server administrators might (at least hypothetically) account for virtually all the observed growth in AMS-IX IPv6 traffic. As to why the AMS-IX number might differ from Arbor's statistic, we know that traffic at exchange points may have a dramatically different composition than traffic measured elsewhere, due in part to the economics of that environment. E.g., continuing to pick on poor old Usenet, people may be willing to exchange Usenet feeds across a settlement-free peering point while they might NOT be willing to exchange Usenet feeds that required (comparatively expensive) transit bandwidth. Those sort of economic choices mean that it is risky to extrapolate Internet-wide traffic statistics from the somewhat atypical settlement-free peering environment. But what sort of growth pattern do we actually see at http://www.ams-ix.net/technical/stats/sflow/ ? That graph *isn't* growing in the characteristic "stair step" pattern one might expect if you were to suddenly flopping full news feeds over onto IPv6. The growth we see there is much more consistent with what you might find from growth in end user traffic (which could be dominated by web, or P2P, or flash videos or scientists ftp'ing large data sets, or yes, even email, who knows, since there's no way to definitively know w/o doing deep packet inspection, which I doubt would be possible in this case). So to bring this post to a close, I continue to believe that IPv6 traffic, at least IPv6 email traffic, remains very, very low, to the point where, as I've previous mentioned, it just hasn't justified DNS block list operator attention in any material way (love to hear about any counter examples, BTW). Regards, Joe St Sauver ([EMAIL PROTECTED]) http://www.uoregon.edu/~joe/ Disclaimer: all opinions strictly my own. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
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@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
Chris Lewis wrote: > Tony Finch wrote: > >> Note that anti-spam blacklists are distributed by more mechanisms than >> just the DNS. Questions of listing policy apply whatever protocol is >> used, so they shouldn't be addressed in a document that just describes >> a DNS-based query protocol. > > I have a similar objection the proposal of a WG for "reputation lists". > > The problem it seems intended to solve is far broader than reputation > lists, and is completely orthogonal to a reputation delivery protocol > standard. [...] Assuming IESG is interested in chartering some WG in this space, it's reasonable to have a discussion about the appropriate scope of said WG. But I don't buy the "content is independent of the container" arguments. In my experience, containers (or protocols, or data representations) nearly always have implied semantics. Even if this isn't intentional, or even if the intention is for them to be free of semantics, they tend to have them in practice, and the semantics tend to be encouraged or enforced by the kinds of tools that were built to deal with those containers. There is also a strong tendency to tailor the data model to make it fit the container. So chances are good that (for example) a data model designed for use with XML would not fit handily into another representation such as email-style headers or DNS resource records. This is part of why I don't assume that DNS is a good way to transmit reputation information. I feel confident that a less constrained protocol would facilitate a better data model. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
Tony Finch wrote: > Note that anti-spam blacklists are distributed by more mechanisms than > just the DNS. Questions of listing policy apply whatever protocol is > used, so they shouldn't be addressed in a document that just describes > a DNS-based query protocol. I have a similar objection the proposal of a WG for "reputation lists". The problem it seems intended to solve is far broader than reputation lists, and is completely orthogonal to a reputation delivery protocol standard. The problems that people ascribe to reputation mechanisms are just as severe in virtually every other type of filtering method. Poorly chosen or implemented content filtering systems have exactly the same problems as poorly chosen or implemented DNSBLs, and have the same implications for "reliability of email". These are SMTP filter signaling protocol issues, and have nothing to do with filtering engine decision mechanisms. The real issue underlying this is standards and practises on how the decision making is implemented _at_ the filter itself. In other words, we need generalized principles of practise how filtering should be signaled through SMTP to enhance reliability, repeatability, and and the ability to identify/resolve problems. I've long been considering the draft of a BCP on how filters should operate. And have written bits and pieces of it in point form. Eg: rejects not bounces, SMTP codes, error texts, C/R, SAV, remediation channels etc. That doesn't belong in a DNSBL protocol specification. It would be entirely missed in a WG about "reputation". It's covered, in part, in the still-draft DNSBL BCP, insofar as they directly relate to details specific to DNSBLs. If a WG were chartered to explore ways to improve filter reliability/interoperability, eg: standardizing filter response mechanisms, I'd participate in that. But that has nothing whatsoever to do with DNSBL protocols - which is nothing more then a delivery mechanism for certain classes of information, the interpretation thereof the choice of who implements whatever uses it. [I use DNSBL protocols for far more than filtering decisions. It works really well to resolve IP addresses into ASNs, allocation ranges, ownership and geolocation information for example.] ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
IPv6 traffic stats (was: Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists))
Joe, On Tue, Nov 11, 2008 at 08:20:11AM -0800, Joe St Sauver wrote: > > I'm not aware of DNS block lists which cover IPv6 address spaces at > this time, probably in part because IPv6 traffic remains de minimis > (see http://asert.arbornetworks.com/2008/8/the-end-is-near-but-is-ipv6/ > showing IPv6 traffic as constituting only 0.002% of all Internet traffic). For the record: It seems that arbornetworks estimates are extremely low to the point where one has to ask whether there were other issues that caused such a low estimate. There is no question that IPv6 traffic is quite low in the Internet. However, many other reports that I have seen recently measure multiple orders of magnitude more IPv6 traffic (for an easily accesible example see: http://www.ams-ix.net/technical/stats/sflow/) David Kessens --- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
The fact that [DNSBLs] are widely used is sad, not a justification for standardization. >> True. The justification is not simply that they are widely used; it >> is that they are widely used, they are often done wrong, they are of >> tremendous value when done right, and of actively negative value >> when done wrong. > I agree that this might be a justification for standardizing some > sort of reputation protocol. But it's not at all clear the document > at hand describes [...] Perhaps. But this is not a place where the IETF gets to choose what will be used. DNSLs are in live use, have been for years, and will continue to be; the IETF can jump up and down all it wants, but that isn't going to change - the question is whether people will use DNSLs with an IETF standard or without one, not whether people will use DNSBLs or something else the IETF likes more. (In principle it's possible people might switch to something better. But I sure don't see any such "something better" even on the horizon, much less in even experimental use - and even if one appears, the adoption time is going to be measured in years. DNSLs will be here for a long time to come.) 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. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML[EMAIL PROTECTED] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
On Tue, 11 Nov 2008, Theodore Tso wrote: > > Questions like, "so how does this work in the face of the expanded > IPv6 address space", ideally should be addressed earlier during the > standardization process, and not in last call (where, "oh well, we'll > just block the whole /48 or /32" might have unfortunate side effects > not forseen yet) That's a matter of listing policy not of protocol. It would be premature to lay down regulations about what can be put in an IPv6 blacklist, since we don't have enough operational experience yet. If you try to guess and the rules turn out not to work in practice, then they will be ignored and cast doubt on the rest of the document. This document should concentrate on the mechanisms, which are simple and uncontroversial, and leave questions of policy aside. Note that anti-spam blacklists are distributed by more mechanisms than just the DNS. Questions of listing policy apply whatever protocol is used, so they shouldn't be addressed in a document that just describes a DNS-based query protocol. > --- but which don't make sense if the goal is to document existing > practice. The goal is to document existing practice AND extend it in a straight- forward way to IPv6 so that implementations are ready BEFORE IPv6 spam becomes a problem. Tony. -- f.anthony.n.finch <[EMAIL PROTECTED]> http://dotat.at/ VIKING NORTH UTSIRE SOUTH UTSIRE: SOUTHEASTERLY BACKING NORTHWESTERLY 5 TO 7. ROUGH OR VERY ROUGH DECREASING MODERATE OR ROUGH. RAIN OR SHOWERS. MODERATE OR GOOD. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
There has been some debate in this forum on whether DNSxLs are an appropriate tools for stopping spam. Whether or not IP-based blocking is a philosophically appropriate method to use, every large scale ISP uses these lists as a first line defense against spam. DNSxLs are a much-used and effective tool in preventing the delivery of spam to the inbox and should be standardized to reduce the cost of implementation of anti-spam measures. The draft outlines the structure and functionality of DNSxLs, but does not dictate or require the use of them. Moreover, it is not the role of this draft to outline the policies for DNSxL listings and procedures for list management. We at Cloudmark support draft-irtf-asrg-dnsbl-07 on the Standards Track and believe that standardization of DNSxL queries and response codes eliminates confusion, eases tool writing, aids email administrators, and reduces everyone's mail infrastructure operating cost. --- Jamie Tomasello Abuse Operations Manager Cloudmark, Inc. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
Theodore mentioned: #Let me get this straight. It's OK to block e-mail messages on the #basis of unauthenticated rumors, Most DNS block lists are based on empirical factors, not rumors. For example, in the case of manual anti-spam block lists, like the Spamhaus SBL, typically listings include spam samples, although other block lists may use different empirical criteria (for example, the Day Old Bread list looks at the age of domain names in determining its coverage). Other lists may identify hosts from dynamic IP address ranges, etc. #but now you are complaining that it's somehow dirty pool to block #a standard based on the same thing? Block lists aren't going to go away if this standard isn't published; block lists have broad community acceptance in and of their own right. On the other hand, without standards, block lists may be run in ways that will primarily disadvantage those who end up blocked by them. Standards for block lists provide a basis for evaluating block list operational practices, and a standard against which poorly run block lists can (and should!) rightfully be pilloried. As such, I think it is unfortunate that some have elected to oppose this draft. #Questions like, "so how does this work in the face of the expanded #IPv6 address space", ideally should be addressed earlier during the #standardization process, and not in last call (where, "oh well, we'll #just block the whole /48 or /32" might have unfortunate side effects #not forseen yet) --- but which don't make sense if the goal is to #document existing practice. I'm not aware of DNS block lists which cover IPv6 address spaces at this time, probably in part because IPv6 traffic remains de minimis (see http://asert.arbornetworks.com/2008/8/the-end-is-near-but-is-ipv6/ showing IPv6 traffic as constituting only 0.002% of all Internet traffic). #There's a big difference between "use" and "Use". If a spamassassin #configuration (by default) uses a DNSBL to add a point or a fraction #of a point to a spam score, where it might take a spam score of 10-15 #before spam is dropped, that's a very different usage model than #someone who, on the unsubstatiated word of SORBS or APEWS, drops the #e-mail on the floor where it is never seen again. Distinguish two types of spam filtering: -- filtering at connect time, where a message that doesn't get accepted for delivery can signal that rejection to the system that's *still connected* to the rejecting MTA -- filtering post connect time, as with SpamAssassin, where a message that ends up scored as spam may (at best) end up filed in a spam folder DNS block lists can be used in either model, but they work best for filtering at connect time because in that model, the delivering host knows that a message has been accepted or rejected. Post connect time filtering means that a message which has apparently been accepted for delivery may never be seen (e.g., if it has been spam foldered or deleted). That critical difference is one reason why DNS blocks lists, used at connect time, are vastly preferable to other non-deterministic approaches, although things like SpamAssassin (particularly with SURBL rules) unquestionably play a crucial role in stopping some types of spam that can't be addressed by connect time DNS block lists. But let me just mention one other pragmatic reason why I believe DNS block lists used at connect time are preferable to some other alternatives, such as site-by-site local anti-spam rules. Consider a sending site that may have a temporary spam problem, perhaps due to a compromised user account, or an accidental system misconfiguration. Having emitted spam, that site ends up being blocked. If it is blocked by one (or two, or some small number ) DNS block lists, after that site has fixed its problem, there's one (or two, or some small ) places they need to go to get unblocked. Moreover, DNS block list operators typically do a nice job of explaining how to get in touch with them, and what sort of process is involved in getting delisted. On the other hand, if thousands or tens of thousands of sites employ unannounced local blocks to deal with that temporary spam problem, you may be trying for months (if not years!) to get all those private site-by-site blocks removed. #And for those who would argue that it's not their problem how the #DNSBL is used, since after all that's the responsibility of the folks #using the DNSBL, DNS block listings are the DNS block list operator's expression of an opinion about a site's email traffic. Just like a food critic's opinion about a restaurant, people can choose to pay attention to that critic's opinions, or not. If the critic likes undercooked tainted and bland food poorly presented by surly wait staff, and that aligns well with your dining preferences, by all means follow that critic's reviews. Most diners, however, with more conventional preferences, will quickly learn to discount or
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
I'm the sponsor of the DNSBL Internet-Draft. I've been following this discussion and it seems to me there have been fair objections raised to putting the document as-is on the Standards Track. I'll consult with the authors about whether they'd like to figure out exactly what the IETF does have consensus to recommend and change the document, or whether Informational would make everybody happy. thanks! Lisa ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
On 11 Nov 2008, at 15:38, Theodore Tso wrote: On Mon, Nov 10, 2008 at 05:12:56PM +, Steve Linford wrote: I certainly agree that there are hundreds of small DNSBLs run from kid's bedrooms which list on incomprehensible wildly over-broad policies and that such DNSBLs are both antagonistic and useless and as a result are used by almost nobody - that's 'market force'. But to pretend that the dozen major DNSBLs make listings based on "unauthenticated rumor" or "because the IP did not have 'mail.' or 'mx.'" is just silly mud- slinging itself based on equally "unauthenticated rumor" and is especially odd if it's coming from within IETF itself. Let me get this straight. Yes please... It's OK to block e-mail messages on the basis of unauthenticated rumors No. Steve Linford The Spamhaus Project http://www.spamhaus.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
> there's a lot of evil e-mail messages out there; the cost of > letting even one of those messages through is unacceptable, > so false positives are OK. This is precisely the sort of thing that should have been covered in much more detail in the Security Considerations section of the draft. > I have no problem with the IETF documenting the world as it exists. > That's what an informational track RFC does. > (where, "oh well, we'll just block the whole /48 or /32" > might have unfortunate side effects not forseen yet) Again, this is missing from the Security Considerations. --Michael Dillon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
On Mon, Nov 10, 2008 at 05:12:56PM +, Steve Linford wrote: > I certainly agree that there are hundreds of small DNSBLs run from kid's > bedrooms which list on incomprehensible wildly over-broad policies and > that such DNSBLs are both antagonistic and useless and as a result are > used by almost nobody - that's 'market force'. But to pretend that the > dozen major DNSBLs make listings based on "unauthenticated rumor" or > "because the IP did not have 'mail.' or 'mx.'" is just silly mud-slinging > itself based on equally "unauthenticated rumor" and is especially odd if > it's coming from within IETF itself. Let me get this straight. It's OK to block e-mail messages on the basis of unauthenticated rumors, but now you are complaining that it's somehow dirty pool to block a standard based on the same thing? After all, it's the same argument; there's a lot of evil e-mail messages out there; the cost of letting even one of those messages through is unacceptable, so false positives are OK. Similarly, there are a lot of bad ideas out there, many of which have folks clamoring to have them be standardized, just as spammers hope to get people to visit their spamvertised web sites. And in both cases, it's "just business" I have no problem with the IETF documenting the world as it exists. That's what an informational track RFC does. There's a process by which a specification gets annointed to become a standard, and others more eloquent than I have already pointed out the dangers of trying to skip steps in the standardization process. Questions like, "so how does this work in the face of the expanded IPv6 address space", ideally should be addressed earlier during the standardization process, and not in last call (where, "oh well, we'll just block the whole /48 or /32" might have unfortunate side effects not forseen yet) --- but which don't make sense if the goal is to document existing practice. > The fact some DNSBLs are in widespread use (I can speak only for > Spamhaus, our DNSBLs are today used by something in the region of 2/3 of > internet networks) is good reason why it's important to publish a > standard and format for the technology. There's a big difference between "use" and "Use". If a spamassassin configuration (by default) uses a DNSBL to add a point or a fraction of a point to a spam score, where it might take a spam score of 10-15 before spam is dropped, that's a very different usage model than someone who, on the unsubstatiated word of SORBS or APEWS, drops the e-mail on the floor where it is never seen again. And for those who would argue that it's not their problem how the DNSBL is used, since after all that's the responsibility of the folks using the DNSBL, I'm reminded of the line from the Tom Lehrer song: "Vonce the rockets go up, who cares vhere they come down? It's not my department, says Verner von Brown." - Ted ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
On Mon, Nov 10, 2008 at 07:04:27PM +, Tony Finch wrote: > On Mon, 10 Nov 2008, Keith Moore wrote: > > > > okay. I found myself wondering if the change in address space size, and > > in granularity of assignment, might make DNSBLs less reliable. Which is > > a different kind of scalability. > > IPv6's bigger address space affects more security mechanisms than just > DNSBLs, such as defensive port scanning, traffic auditing, etc. > > http://www.watersprings.org/pub/id/draft-chown-v6ops-port-scanning-implications-02.txt Thanks Tony - that draft has now emerged as RFC5157: http://www.ietf.org/rfc/rfc5157.txt The granularity of the address space that might appear in a blacklist is an interesting question. I would guess that where today a single IPv4 address appears, a whole IPv6 /64 would be required, at least, since a client on a IPv6 link could in principle use any of the 2^64 available host addresses.But it may be worse, if whole /48's are assigned to DSL users for example (although there seems to be pushback to /56 for SOHO type networks).The question then is whether the single IPv6 address or link it is on is blacklisted, or whether the blacklist includes the 'default' site prefix size. On a related tack, I've been gathering stats on our recorded IPv6 transport mail volumes and identified spam since Dublin, and will analyse these soon and pop out a draft with appropriate observations.We've seen a fairly consistent figure of 50% of our IPv6 transport connections being classified as spam by our MailScanner system since Dublin. Tim ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
On Mon, 10 Nov 2008, Keith Moore wrote: > > okay. I found myself wondering if the change in address space size, and > in granularity of assignment, might make DNSBLs less reliable. Which is > a different kind of scalability. IPv6's bigger address space affects more security mechanisms than just DNSBLs, such as defensive port scanning, traffic auditing, etc. http://www.watersprings.org/pub/id/draft-chown-v6ops-port-scanning-implications-02.txt Tony. -- f.anthony.n.finch <[EMAIL PROTECTED]> http://dotat.at/ WIGHT PORTLAND PLYMOUTH: SOUTHWEST VEERING WEST 6 TO GALE 8. ROUGH OR VERY ROUGH. RAIN THEN SQUALLY SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR AT FIRST. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
Tony Finch wrote: > On Mon, 10 Nov 2008, Keith Moore wrote: >> Tony Finch wrote: >> >>> In any case, DNSBLs should scale roughly according to the size of the >>> routing table, not the size of the address space. >> What does it mean for a DNSBL to "scale"? > > I was referring to the number of entries that have to be maintained. okay. I found myself wondering if the change in address space size, and in granularity of assignment, might make DNSBLs less reliable. Which is a different kind of scalability. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
On Mon, 10 Nov 2008, Keith Moore wrote: > Tony Finch wrote: > > > In any case, DNSBLs should scale roughly according to the size of the > > routing table, not the size of the address space. > > What does it mean for a DNSBL to "scale"? I was referring to the number of entries that have to be maintained. Tony. -- f.anthony.n.finch <[EMAIL PROTECTED]> http://dotat.at/ MALIN HEBRIDES: CYCLONIC BECOMING NORTHWEST 7 TO SEVERE GALE 9. VERY ROUGH OR HIGH. SQUALLY SHOWERS. MODERATE OR POOR. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
Tony Finch wrote: > On Mon, 10 Nov 2008, Keith Moore wrote: >> I suspect it will be very difficult to make IPv6 DNSxLs work anywhere >> nearly as well as IPv4 DNSxLs, because in IPv6 it is fairly easy to use >> a different address for every SMTP conversation. > > I expect that attack will make /48 or /64 listings common. This has the > obvious downside of an increased risk of one infected host spoiling email > connectivity for its immediate neighbours, even more than is already the > case for IPv4 DNSBLs. Perhaps ISPs and hosting providers can mitigate that > by enforcing address allocation policies. Or perhaps enterprise networks will be forced to outsource their mail submission to third parties with supposedly "trustworthy" addresses. Which IMHO would not be a desirable result. > In any case, DNSBLs should scale roughly according to the size of the > routing table, not the size of the address space. What does it mean for a DNSBL to "scale"? Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
On Mon, 10 Nov 2008, Keith Moore wrote: > > I suspect it will be very difficult to make IPv6 DNSxLs work anywhere > nearly as well as IPv4 DNSxLs, because in IPv6 it is fairly easy to use > a different address for every SMTP conversation. I expect that attack will make /48 or /64 listings common. This has the obvious downside of an increased risk of one infected host spoiling email connectivity for its immediate neighbours, even more than is already the case for IPv4 DNSBLs. Perhaps ISPs and hosting providers can mitigate that by enforcing address allocation policies. In any case, DNSBLs should scale roughly according to the size of the routing table, not the size of the address space. Tony. -- f.anthony.n.finch <[EMAIL PROTECTED]> http://dotat.at/ FISHER: SOUTHWEST 6 TO GALE 8 BACKING SOUTH 5 OR 6. VERY ROUGH BECOMING MODERATE OR ROUGH. SHOWERS. MODERATE OR GOOD. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
der Mouse wrote: > [Keith Moore] >>> The fact that [DNSBLs] are widely used is sad, not a justification >>> for standardization. > > True. The justification is not simply that they are widely used; it is > that they are widely used, they are often done wrong, they are of > tremendous value when done right, and of actively negative value when > done wrong. I agree that this might be a justification for standardizing some sort of reputation protocol. But it's not at all clear the document at hand describes a protocol which is technically sound, and it certainly doesn't have rough IETF consensus. I'm willing to defer judgment about whether such a protocol might reasonably resemble DNSxL, or whether it can reasonably use DNS at all - but I have reason to doubt it. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
Steve Linford wrote:
> I certainly agree that there are hundreds of small DNSBLs run from kid's
> bedrooms which list on incomprehensible wildly over-broad policies and
> that such DNSBLs are both antagonistic and useless and as a result are
> used by almost nobody - that's 'market force'. But to pretend that the
> dozen major DNSBLs make listings based on "unauthenticated rumor" or
> "because the IP did not have 'mail.' or 'mx.'" is just silly
> mud-slinging itself based on equally "unauthenticated rumor" and is
> especially odd if it's coming from within IETF itself.
It's only odd if you refuse to recognize our experiences as valid.
> The fact some DNSBLs are in widespread use (I can speak only for
> Spamhaus, our DNSBLs are today used by something in the region of 2/3 of
> internet networks) is good reason why it's important to publish a
> standard and format for the technology.
Wrong. Read RFC 2026 and stop demanding that we change our technical
criteria just for you.
> Like everyone we'd like to see poorly managed, arrogant or anonymous
> DNSBLs given a high standard to attain ('shape up or ship out'), since
> an irresponsible DNSBL listing something for little discernible reason
> is what creates "I hate all DNSBLs" poster children. Lets have the
> technology, standards and how to do it correctly published for the
> future and leave aside silly "I once had a client blacklisted"
> arguments. The question "are DNSBLs bad for the world" or "are DNS
> queries a bad use" is irrelevant to the need for draft-irtf-asrg-dnsbl
> and a false argument against it.
>
> I can see no legitimate reason for IETF not publishing
> draft-irtf-asrg-dnsbl.
The proposal has neither technical soundness nor rough consensus of the
community.
Keith
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
[Keith Moore] >> The fact that [DNSBLs] are widely used is sad, not a justification >> for standardization. True. The justification is not simply that they are widely used; it is that they are widely used, they are often done wrong, they are of tremendous value when done right, and of actively negative value when done wrong. [John C Klensin] > Sadly, I have to agree with Keith. While these lists are a fact of > life today, and I would favor an informational document or document > that simply describes how they work and the issues they raise, > standardizing them and formally recommending their use is not > desirable at least without some major changes in our email model and > standards for what gets addresses onto --and, more important, off > of-- those lists. And this, I mostly disagree with. Just because something is something we'd rather not have around does not mean standardizing it is a bad idea. SSH is an example; I would much rather the net were still the open, friendly place it was back in the ARPAnet and NSFnet days, where SSH was unnecessary. But that's no longer today's net, and SSH or something like it is necessary; I think standardizing it is a Good Thing (indeed, a necessary thing in the case of SSH). Similarly, I too find DNSBLs' necessity regrettable. But I do find them necessary, and I think we're better off standardizing those aspects that are currently agreed-upon enough to standardize. I do not think that standards for how addresses get onto and off of DNSBLs is even desirable. As long as the list is technically well-run and adheres to what it tells its users its (de)listing policies are, exactly what those policies are is entirely up to the list; a wide variety of policies is good because there is an equally wide variety of receiving sites' desires - and because the price to the net of a DNSL nobody uses is so close to zero as no matter, so there's no harm in having a wide variety available to pick from. And that "technically well-run" is the part that I think not only can be standardized but should be standardized. Not that my opinion counts for all _that_ much, since I'm not the one doing the work. But it's not total randomness; email operations and administration has been part of my paid job for some 18 of the last 25 years, and I was on the CAUCE Canada board before we merged with CAUCE USA. (I think I'm actually still technically on CAUCE North America board, but I've been trying to get out of abuse-fighting for a year or two now). /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML[EMAIL PROTECTED] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
On Sun, 9 Nov 2008, Tony Hansen wrote: > > Does anyone have issues with the use of this protocol for WHITE lists? DNSWLs already exist and are used by e.g. SpamAssassin. Tony. -- f.anthony.n.finch <[EMAIL PROTECTED]> http://dotat.at/ TYNE DOGGER FISHER: SOUTHWEST 6 TO GALE 8, BACKING SOUTH 5 OR 6 IN FISHER. ROUGH OR VERY ROUGH, OCCASIONALLY MODERATE LATER. SHOWERS. MODERATE OR GOOD. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
I'm coming in a bit late into this strange argument, but from what
I'm reading it sounds like someone *from IETF* is contesting the need
for DNSBLs and thus the need for draft-irtf-asrg-dnsbl and on grounds
which are misguided at best.
I certainly agree that there are hundreds of small DNSBLs run from
kid's bedrooms which list on incomprehensible wildly over-broad
policies and that such DNSBLs are both antagonistic and useless and
as a result are used by almost nobody - that's 'market force'. But to
pretend that the dozen major DNSBLs make listings based on
"unauthenticated rumor" or "because the IP did not have 'mail.' or
'mx.'" is just silly mud-slinging itself based on equally
"unauthenticated rumor" and is especially odd if it's coming from
within IETF itself.
The fact some DNSBLs are in widespread use (I can speak only for
Spamhaus, our DNSBLs are today used by something in the region of 2/3
of internet networks) is good reason why it's important to publish a
standard and format for the technology.
Like everyone we'd like to see poorly managed, arrogant or anonymous
DNSBLs given a high standard to attain ('shape up or ship out'),
since an irresponsible DNSBL listing something for little discernible
reason is what creates "I hate all DNSBLs" poster children. Lets have
the technology, standards and how to do it correctly published for
the future and leave aside silly "I once had a client blacklisted"
arguments. The question "are DNSBLs bad for the world" or "are DNS
queries a bad use" is irrelevant to the need for draft-irtf-asrg-
dnsbl and a false argument against it.
I can see no legitimate reason for IETF not publishing draft-irtf-
asrg-dnsbl.
Steve Linford
The Spamhaus Project
http://www.spamhaus.org
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
Steven M. Bellovin wrote: My concern is centralization of power. If used properly, white lists are fine. If used improperly, they're a way to form an email cartel, forcing organizations to buy email transit from a member of the inner circle. Steve, Email reputation lists have been around for a very long time. The current specification codifies this existing practice. So we have plenty of track record to test your concern. Perhaps you know of some pattern that validates that concern, but I don't. Such services have always been easy to set up and, indeed, there is a wide range of reputation services. (Positive reputation services are more recent so there is a smaller set to evaluate... so far.) A standard reduces switching costs, so that consumers of reputation data are not locked in to their current reputation provider. Hence, standardizing the details for obtaining reputation data -- postivie or negative -- ought to mitigate against centralization. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
John Levine wrote: > As I said a few messages up in this string, although the structure of > IPv4 DNSxLs has long since been cast in concrete, IPv6 DNSxLs aren't > that mature yet and one of my goals was to make them interoperate > equally well so, for example, if you find you're using cruddy ones you > can easily switch to better ones. I suspect it will be very difficult to make IPv6 DNSxLs work anywhere nearly as well as IPv4 DNSxLs, because in IPv6 it is fairly easy to use a different address for every SMTP conversation. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
> -Original Message- > From: Keith Moore [mailto:[EMAIL PROTECTED] > > > Keith - I encourage you to consult with several very large > scale email domains around the world to see if they think > that DNSxBLs are useful, effective, and in widespread use or not. > > Jason - I encourage you to consult with users whose mail > isn't getting delivered, and see whether they think DNSBLs > are useful and effective, or whether their mail is > effectively being bounced by third parties who aren't > accountable for their actions. The buck ultimately stops with any mail admin (or user of any particular technology), not the DNSxLs and any other filtering tools they may choose to employ. As for consulting with users, you will find me (and my team) posting (and reading of course) almost daily on the Comcast section of BroadbandReports and our customer support forum's email section (http://forums.comcast.net). I could give you countless other examples of how I am my team works with senders and customers, and works to increase our transparency (such as http://postmaster.comcast.net). I work hard to be in touch with customers, and consider it a centrally important part of my job to understand how my team's use of technology affects our customers and other users on the Internet. Also, I am sure you would not be surprised to know there is a correlation betewen spam effectiveness and user satisfaction with email. Yes, there are always individual sender problems, but no matter the tool or technology you always have exceptional use cases that must be worked through. Regards Jason ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
> That's a rather narrow view. Very large numbers of people think that > Instant Messaging is a far superior alternative to DNSBLs, not to > mention VoIP, web forums and other variations on the theme. I can certainly believe that there are people who think that, but if those very large numbers of people aren't even aware that IM, VoIP, and web forums also use DNSBLs and DNSWLs to manage their abuse problems, it's hard to see how their impressions would be helpful here. > I think it is a positive thing to document the technology of DNSBLs > but I have no idea why this has come to the IETF. As I said a few messages up in this string, although the structure of IPv4 DNSxLs has long since been cast in concrete, IPv6 DNSxLs aren't that mature yet and one of my goals was to make them interoperate equally well so, for example, if you find you're using cruddy ones you can easily switch to better ones. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
Steven M. Bellovin schrieb: > In some sense, I have more trouble with white lists than black lists. > > My concern is centralization of power. If used properly, white lists > are fine. If used improperly, they're a way to form an email cartel, > forcing organizations to buy email transit from a member of the inner > circle. That is fundamentally true, and is the very reason dnswl.org is _not_ built around a business model, but as an all-volunteer organisation. The "value" of such an organisation is the trust given by the users of the whitelist data. Abuse of this trust would very fast be sanctioned by not using the data any more. However, this is independent from the technical specification of the protocol, which I think is valuable. While this draft does not specify the only protocol available to query our data, it is by far (in the high 90%-region) the most important one (either through queries to our public servers or through local/private mirrors). -- Matthias ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
Steven M. Bellovin wrote: > On Sun, 09 Nov 2008 23:40:43 -0500 > Tony Hansen <[EMAIL PROTECTED]> wrote: > In some sense, I have more trouble with white lists than black lists. > > My concern is centralization of power. If used properly, white lists > are fine. If used improperly, they're a way to form an email cartel, > forcing organizations to buy email transit from a member of the inner > circle. Hi Steven, long time... Sort of a protection racket. This only works insofar as the mail receivers (the ones who choose to deploy a whitelist) is willing to let them. Receivers are driven, first and foremost, by their users's complaint rates. Receivers will notice increased complaint rates from a whitelist like this, and begin to discount their input. As they also do with FP rates on the blacklists they use. We see that now in take-up rates of various DNSBL/DNSWLs. Much as, say, people realized that TrustE logos didn't mean very much. There's a much larger potential with proprietary reputation systems - the buy-in costs are high, so it eventually becomes impossible for new reputation vendors to get into the act, and receivers are reluctant to switch vendors because they have to put yet another proprietary thingie in their MTAs. [A few years ago, at a MAAWG session, I caused a bit of slack-jawed consternation when I strongly put forth the idea that reputation vendors had to move to open protocols if they wanted acceptance at more than a few of the very largest ISPs that could afford it. I'm glad to report that at least one or two have since seen the light.] In an standard protocol environment, startup costs are minimal, receivers find it very easy to switch or mix-and-match. Same goes with negative reputation. A standardized open protocol greatly reduces the likelyhood of cartelish behaviour. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
On Sun, 09 Nov 2008 23:40:43 -0500 Tony Hansen <[EMAIL PROTECTED]> wrote: > I'm personally very interested in getting the format for querying DNS > *white* lists standardized. I want to be able to use DNSWLs as part of > *positive reputation* checking: given an *authenticated* domain name > (say, with DKIM), can we say something positive about them beyond > "they send email"? > > The protocol described in this draft covers both cases, both positive > and negative checking. > > While the majority of the examples in the document concentrates on > negative examples, the protocol *is* useful for the positive case. > > Does anyone have issues with the use of this protocol for WHITE lists? > In some sense, I have more trouble with white lists than black lists. My concern is centralization of power. If used properly, white lists are fine. If used improperly, they're a way to form an email cartel, forcing organizations to buy email transit from a member of the inner circle. --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
I'm personally very interested in getting the format for querying DNS *white* lists standardized. I want to be able to use DNSWLs as part of *positive reputation* checking: given an *authenticated* domain name (say, with DKIM), can we say something positive about them beyond "they send email"? The protocol described in this draft covers both cases, both positive and negative checking. While the majority of the examples in the document concentrates on negative examples, the protocol *is* useful for the positive case. Does anyone have issues with the use of this protocol for WHITE lists? Tony Hansen [EMAIL PROTECTED] John C Klensin wrote: > Sadly, I have to agree with Keith. While these lists are a > fact of life today, and I would favor an informational document > or document that simply describes how they work and the issues > they raise, standardizing them and formally recommending their > use is not desirable at least without some major changes in our > email model and standards for what gets addresses onto --and, > more important, off of-- those lists. > > john > > > --On Friday, 07 November, 2008 18:38 -0500 Keith Moore > <[EMAIL PROTECTED]> wrote: > >> DNSBLs work to degrade the interoperability of email, to make >> its delivery less reliable and system less accountable for >> failures. They do NOT meet the "no known technical omissions" >> criterion required of standards-track documents. >> >> The fact that they are widely used is sad, not a justification >> for standardization. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
> And what does this have to do with the technical details of > running and using one? We all know that spam stinks and > DNSBLs stink, too. > Unfortunately, the alternatives to DNSBLs are worse. That's a rather narrow view. Very large numbers of people think that Instant Messaging is a far superior alternative to DNSBLs, not to mention VoIP, web forums and other variations on the theme. Fortunately, the IETF has done some good work in the area of SIP and XMPP has steadily been gaining traction. I think it is a positive thing to document the technology of DNSBLs but I have no idea why this has come to the IETF. Maybe it is a veiled test of the IETF's relevance to the 21st century Internet. --Michael Dillon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
Matthias Leisi wrote: > [Disclosure: I am the leader of the dnswl.org project; I provided some > input into the DNSxL draft as far as it concerns whitelists.] > > Keith Moore schrieb: > >> These incidents happen one at a time. It's rarely worth suing over a >> single dropped message, and yet the aggregate amount of harm done by IP >> based reputation services is tremendous. > > I would not want to reduce the situation to blacklists only. You use the > correct term - IP based reputation services - but fail to mention that > this includes whitelists, and that decisions other than "drop" can be > made based upon data returned by such services. I suspect DNSWLs have problems also, but I haven't tried to analyze the problems with DNSWLs to the extent I have the problems with DNSBLs. > Regarding the "dropped message": While outside the scope of the DNSxL > draft, it is pretty much consensus that messages should not be dropped > in the sense of deleted or "stored in a seldomly reviewed quarantine > folder", but that a clear SMTP 5xx error code should be returned. I don't think it should be outside the scope of a standard. > I believe it is generally agreed that false positives are the main risk > with spam filter solutions. This applies both to individual tools like > DNSxLs and to the "filtering machine" as a whole as perceived by the > recipient (and the sender). No automated solution can guarantee the > absence of false positives. > > On the other hand, the manual solution is far worse in terms of false > positives, in my experience - the human error rate is pretty high when > eg a spammy inbox must be reviewed manually. Agreed. But it is not uniform for all recipients - it depends highly on how much legitimate mail they receive, how much spam they receive, and the similarity between the two. And there's a important difference in liability between a recipient filtering his own mail and an unrelated third party filtering it for him. >> And the relative number of complaints is not >> a reliable indicator of those costs. > > It's probably the best indicator available? perhaps, but that doesn't make it a compelling argument. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
[Disclosure: I am the leader of the dnswl.org project; I provided some input into the DNSxL draft as far as it concerns whitelists.] Keith Moore schrieb: > These incidents happen one at a time. It's rarely worth suing over a > single dropped message, and yet the aggregate amount of harm done by IP > based reputation services is tremendous. I would not want to reduce the situation to blacklists only. You use the correct term - IP based reputation services - but fail to mention that this includes whitelists, and that decisions other than "drop" can be made based upon data returned by such services. Regarding the "dropped message": While outside the scope of the DNSxL draft, it is pretty much consensus that messages should not be dropped in the sense of deleted or "stored in a seldomly reviewed quarantine folder", but that a clear SMTP 5xx error code should be returned. DNSBLs in conjunction with SMTP 5xx error codes actually increase the value of the overall email system by enhancing it's reliability. > receive. But they're not as likely to know about messages that they > never receive because of false positives, so of course they're less > likely to complain about them. And the cost (to sender or recipient) of > a message blocked for bogus reasons can be far higher than the cost to > the recipient of a spam. I believe it is generally agreed that false positives are the main risk with spam filter solutions. This applies both to individual tools like DNSxLs and to the "filtering machine" as a whole as perceived by the recipient (and the sender). No automated solution can guarantee the absence of false positives. On the other hand, the manual solution is far worse in terms of false positives, in my experience - the human error rate is pretty high when eg a spammy inbox must be reviewed manually. It is true that many spam filter solutions are short on "ham rules" which would offset erroneous (or bogus, as you chose to call it) "spam rules". The reason is obvious: most ham rules would be trivially to forge for a spammer -- something which is not practical with IP addresses. That's why IP addresses are so important for spam filter decisions, both for black- and for whitelisting. > And the relative number of complaints is not > a reliable indicator of those costs. It's probably the best indicator available? -- Matthias, for dnswl.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
Chris Lewis wrote: > So, where's this accountability gap you keep talking about? The gap is where ISPs can drop my mail without a good reason, and without my having any recourse against them. The gap increases when they delegate those decisions to a third party. It increases further when the mail is dropped without any notice to sender or recipient. These incidents happen one at a time. It's rarely worth suing over a single dropped message, and yet the aggregate amount of harm done by IP based reputation services is tremendous. > I found out what our users thought of DNSBLs when I accidentally turned > off DNSBL queries. We were flooded with hundreds of complaints about > the spam. We get _far_ fewer complaints about false positives we have. You're comparing apples to oranges here. It's not surprising that recipients complain about an increase in the amount of spam they receive. But they're not as likely to know about messages that they never receive because of false positives, so of course they're less likely to complain about them. And the cost (to sender or recipient) of a message blocked for bogus reasons can be far higher than the cost to the recipient of a spam. And the relative number of complaints is not a reliable indicator of those costs. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
Keith Moore wrote: > Livingood, Jason wrote: > >> Keith - I encourage you to consult with several very large scale email >> domains around the world to see if they think that DNSxBLs are useful, >> effective, and in widespread use or not. > > Jason - I encourage you to consult with users whose mail isn't getting > delivered, and see whether they think DNSBLs are useful and effective, > or whether their mail is effectively being bounced by third parties who > aren't accountable for their actions. DNSBL operators can and do get sued for their actions. Sometimes rightfully so. Further, accountability both for the block and its remediation, rests mostly with the admin who deploys the filters, whether it be something they've designed themselves, or choose to delegate to someone else (whether it be DNSBL, Brightmail filter downloads or A-V signature downloads etc). Which in our case is _me_. I don't get to blame others for _my_ choices. So, where's this accountability gap you keep talking about? I found out what our users thought of DNSBLs when I accidentally turned off DNSBL queries. We were flooded with hundreds of complaints about the spam. We get _far_ fewer complaints about false positives we have. So the real result of your suggestion is clear. You need to do what Jason suggests. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
Livingood, Jason wrote: > Keith - I encourage you to consult with several very large scale email > domains around the world to see if they think that DNSxBLs are useful, > effective, and in widespread use or not. Jason - I encourage you to consult with users whose mail isn't getting delivered, and see whether they think DNSBLs are useful and effective, or whether their mail is effectively being bounced by third parties who aren't accountable for their actions. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
John C Klensin wrote: > As a thought experiment, if Nortel or Comcast are developing > these lists and like them, are they willing to assume liability? One would _assume_ you mean "assume liability if we lost a lawsuit", rather than fork out money to anybody who sticks their hand out. Well, of course we do. We wouldn't be doing it if we didn't - we can't wave a magic wand and escape the law. We have MUCH bigger worries than legal liability like you're talking about here. Losing an important sale because of a filter mistake is a far more likely risk than getting sued. So, no lost legitimate email is the absolute overriding priority. Or, are you thinking that a whole new set of law needs to be created to cover the source IP-based version of filtering, and holds DNSBL operators to a higher standard than anyone else? Why? There have been many legal actions already. A few losses, but mostly wins. Note also: e360 vs Comcast. e360 sues Comcast for source-IP blocking them. Case thrown out on summary judgement. Comcast has absolute right to do it explicitly enshrined in the DMCA "hold harmless for good faith blocking of objectionable email" clause. This is probably extensible to the suppliers that ISPs use to do that blocking. Hence, DNSBLs are also immune as long as the plaintiff can't prove bad faith. That case is not entirely over yet, but the final result isn't going to be any different. Comcast's counter to the initial complaint is amazing reading. > If not, what does that say about the model? Legal theory around DNSBLs has already been partially established in case law. Your questions have already had their answers demonstrated in a way that only enhances the model. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
John C Klensin wrote: > I've got two separate and unrelated incidents in the last 10 > days in which RBL lists have decided to block some (but not all) > of Comcast's outbound mail servers. Interestingly, this draft is about both blacklists and whitelists. Many large domains maintain whitelists of other large mail domains. For example, our comcast.net outbound servers are all listed here at http://postmaster.comcast.net/outbound-mail-servers.aspx and you can get an RSS feed of the addresses so that you can get updates. But every large sender tends to do this in an entirely different way. And, here is how we list our dynamic IP address space, at http://postmaster.comcast.net/dynamic-IP-ranges.aspx and in RSS feed at http://postmaster.comcast.net/dynamic-ip-ranges.xml. In the case of dynamic space, several DNSxBLs exist that aggregate ISP dynamic IP space to make it easier on large domains to put all of those together. Jason ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
> I've got two separate and unrelated incidents in the last 10 days in > which RBL lists have decided to block some (but not all) of > Comcast's outbound mail servers. ... I remain baffled by this line of argument. If anecdotes about DNSBLs not run the way you like disqualify even describing the technology in a standards track document, how could you in good concience allow the publication of RFC 5321, which describes the technology used to send several billion phishes, 419 scams, and penis pill ads every day? The vast majority of SMTP usage, over 95% of all transactions, is for mail that is unwanted, fraudulent, and probably illegal. I dare say that considerably less than 95% (heck, less than 1%) of DNSBL lookups produce a problematic result. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
-Original Message- From: [EMAIL PROTECTED] on behalf of Keith Moore Sent: Sat 11/8/2008 2:50 PM To: John Levine Cc: [EMAIL PROTECTED]; ietf@ietf.org Subject: Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists) Keith Moore wrote: >and there's a billion and a half users whose email is being degraded by >such mechanisms. >if you ask them whether they want to not receive spam, they'll say yes. > if you ask them whether they want their incoming mail filtered on the >basis of unsubstantiated rumor and unreliable identifiers, they'll say no. Keith - I encourage you to consult with several very large scale email domains around the world to see if they think that DNSxBLs are useful, effective, and in widespread use or not. Regards Jason ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
--On Saturday, 08 November, 2008 16:46 -0800 David Conrad <[EMAIL PROTECTED]> wrote: > I thought the role of the IETF was to define standards that > facilitate interoperability implementations of protocols, not > make value judgements about operational decisions made by > folks who use those protocols. > > Is the goal here to force the folks who are interested in > standardizing DNSBLs to do so in another venue? David, I would be much more sympathetic to the notion that this was just about standardizing neutral formats to facilitate interoperability among those who had decided to use these lists if the Security Considerations section addressed a broader range of the issues that have been raised in this thread. It does not, and that leads one to wonder whether that argument from some of the participants is a little bit disingenuous. And, in theory, the IETF still has a system of recommendation levels for standards-track documents on the books that is orthogonal to maturity levels and that includes such categories as "recommended", "not recommended", and something like "mandatory". While we haven't used those categories regularly for years, the default remains, AFAIK, "recommended" ... that that doesn't mean a neutral "we recommend that you use this data format if you decide to do that thing". In addition, although we were well into the thread before it came up, if the ASRG is planning to ask for publication of a "companion document" that specifies how to use this stuff, as a BCP no less, the two documents should be treated in the same way we would normally treat WG or conventional individual submission documents that were that closely related and put into Last Call together. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
--On Saturday, 08 November, 2008 13:46 -0700 Doug Ewell <[EMAIL PROTECTED]> wrote: > Several years ago, my employer's e-mail spam filter blocked > the Unicode mailing list as a "suspect site." Earlier this > year, GoDaddy (registrar of my domain name) did the same, and > it took months to figure out what was going on. It's > conceivable that someone might have used this high-profile > mailing list as part of a spam, at some point, but to block > the entire domain is complete overkill. I'm no expert on > e-mail security, and I detest spam, but there is such a thing > as a cure that is worse than the disease. I've got two separate and unrelated incidents in the last 10 days in which RBL lists have decided to block some (but not all) of Comcast's outbound mail servers. Note that these are not messages being sent from the desktop of a Comcast cable modem customer direct to a destination but messages sent from the customer to Comcast's mail servers acting as submission servers, to a destination... and blocked at the last step. That class of thing has become an epidemic. What I don't know is whether Comcast is moving servers in and out of address pools that are used to service residential users (so that the RBL lists can't keep up) or whether "bad guy by rumor" tactics are being used to punish Comcast for aggressive use of RBLs, or whether this is just random nonsense.I do know an increasing number of Comcast customers who are switching their primary mailboxes to other services because of seemingly-unpredictable blocks to their incoming and outgoing messages. Perhaps Comcast likes that -- lowers expenses without lowering revenues -- but I hope that motivation has not been considered. Two additional comments to avoid sending more messages in this thread, parts of which have started to resemble a religious war. * The "reject at SMTP time, rather than generate NDNs, all there will be no blowback problems" is bogus unless one managed to design one's mail environment to completely eliminate relaying or one has some other highly secure and reliable way to authenticate senders (not just sending servers or permission of identities to send from those servers). A change to get rid of relaying would be, IMO, another significant change in the architecture, whether one believes it is feasible or not. * Regardless of the particulars of the email environment and what people (I think temporarily) have been able to get away with on the Internet, the business of being a third-party who evaluates and/or certifies the reputations of others is traditionally a very serious one in the real world. Organizations that do it traditionally assume huge liabilities that they may, or may not, be able to constrain depending on what people use the reputations to do. Libel laws often apply, especially if ones procedures are lax enough (or depend enough on unsubstantiated rumors) to constitute reckless disregard of the truth. Many years ago, when the IETF and others still believed in general-purpose cert issuers and we weren't far away from the "one true root" model, Jeff Schiller famously commented that an organization would have to be insane to take on that general purpose role without sovereign immunity. If IP addresses weren't such a lousy instrument, I could find myself believing in RBL databases if the parties taking responsibility for the entries would identify themselves in clear and authenticatable ways and post bonds against accidentally damaging the reputations of people and enterprises by accusing them of being spammers. That is unlikely in the present environment because the current environment gets one blacklisted by inference and anonymous rumor, with some list maintainers bragging about how they can't be found or affected by legal processes. It is not clear to me that such arrangements would have much to do with the DNS, for reasons that we should probably all understand by now. It it also not clear to me that facilitating interoperation among that class of operators is a good thing, although I could be convinced that it might be a step toward more maturity and responsibility in the business. As a thought experiment, if Nortel or Comcast are developing these lists and like them, are they willing to assume liability? If not, what does that say about the model? john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
--On Friday, 07 November, 2008 12:10 -0500 Sam Hartman <[EMAIL PROTECTED]> wrote: > It seems quite clear to me that RFC 2418 does not apply at all > to the output of an RG. From a process and consensus building > standpoint, this last call needs to be treated the same as an > individual submission, not WG output. RGs are not required to > maintain the level of openness, minutes, etc that WGs do. > Thus, they don't get the presumption of consensus that a WG > does and the comments in 2418 about last calls do not apply. > Even if a particular RG is open, it's still not a WG; just as > we would expect input from an external organization to be > treated through the individual process regardless of the > openness of that organization, we should do the same for IRTF > output. Because of exactly this reasoning, there was once a time that the IAB and ISRG Chair insisted on keeping the ISRG/IETF boundary clear by prohibiting RGs from producing standards-track documents. If something got close to the point at which standardization was appropriate, either (1) the document had to be handled as an individual submission, with, at most, an acknowledgment to the RG or (2) the RG got shut down with advice to go through the IETF's WG chartering process. Unless my memory is failing me, one of the people who is now advocating giving the RG status comparable to WGs was strongly supportive of that model. Perhaps an RG might produce a standards-track document as an accidental side-effect of its work and the community should be relaxed about that under the principle of not putting rigid rules ahead of good sense. It still wouldn't rate treatment as a WG for the reasons Sam cites. But, if an RG starts regularly producing candidate documents for standards track or BCPs (and I note that this thread has led to a discussion of at least one "companion document" for which BCP processing is expected to be requested RSN), then it isn't doing research as its exclusive focus any more: at least a non-trivial amount of its effort has become protocol engineering and its close relatives. Independent of what happens with this document, I urge the IRTF Chair and the IAB to bring that situation under control. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
On Nov 8, 2008, at 4:07 PM, John Levine wrote: And what does this have to do with the technical details of running and using one? We all know that spam stinks and DNSBLs stink, too. Unfortunately, the alternatives to DNSBLs are worse. This whole discussion is confusing. I thought the role of the IETF was to define standards that facilitate interoperability implementations of protocols, not make value judgements about operational decisions made by folks who use those protocols. Is the goal here to force the folks who are interested in standardizing DNSBLs to do so in another venue? Thanks, -drc ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
>Indeed; reputation system for the reputation servers! Of course, if >DNSBL operaters were to find the that shoe was on the other foot, such >that their reputations were getting judged by the same criteria that >sites are declared "unclean" (i.e., by unauthenticated rumor), ... Why do you assume that nobody looks at the quality of DNSBLs? See, for example, http://stats.dnsbl.com/ And what does this have to do with the technical details of running and using one? We all know that spam stinks and DNSBLs stink, too. Unfortunately, the alternatives to DNSBLs are worse. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
On Sat, Nov 08, 2008 at 05:41:41PM -0500, Keith Moore wrote: > I really think that if you can design and standardize a protocol for > reporting reputation which includes a mechanism for making the > reputation service accountable to end users, and also is reasonably > secure, you might seriously improve email reliability. I just don't > think that DNSBL is good enough for that and I doubt that DNS can be > stretched far enough to make that work well. Indeed; reputation system for the reputation servers! Of course, if DNSBL operaters were to find the that shoe was on the other foot, such that their reputations were getting judged by the same criteria that sites are declared "unclean" (i.e., by unauthenticated rumor), maybe there would be more attention and care towards some secure, accountable way for conclusions to be reached on some particular host's reputations, whether it is running a SMTP server or a DNSBL, and for a more secure, authenticated, and accountable way for that reputation to be carried across the network. - Ted ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
Paul Hoffman wrote: > The IETF has repeatedly tried and failed to fix the "RFC levels" problem. Paul, our criteria for standards-track documents haven't changed in several years. Sure they're imperfect but that's not a justification for abandoning them. And this document doesn't meet them. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
You keep citing 1.5 billion users. I haven't asked all of them, of course, but I keep finding that users don't trust their email to be reliable, and they don't know how to find an email service that is reliable. Mostly they maintain several different email accounts and try sending from multiple accounts in the hopes that one of those messages will get there. Those that haven't given up on email entirely, that is. I really think that if you can design and standardize a protocol for reporting reputation which includes a mechanism for making the reputation service accountable to end users, and also is reasonably secure, you might seriously improve email reliability. I just don't think that DNSBL is good enough for that and I doubt that DNS can be stretched far enough to make that work well. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
>Several years ago, my employer's e-mail spam filter blocked the Unicode >mailing list as a "suspect site." Earlier this year, GoDaddy (registrar >of my domain name) did the same, and it took months to figure out what >was going on. What connection does any of this have to do with DNSBLs? There are lots of less than fabulous ways to manage a mail system poorly, most of which have nothing to do with looking up IP addresses in a DNS list. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
Chris Lewis wrote: > Keith Moore wrote: >> I think you're missing the point. > > Oh, no, I fully understand the point. In contrast, I think you're > relying on false dichotomies. > > For example: > >> Better "interoperation" of a facility that degrades the reliability of >> email, by encouraging an increased reliance on dubious filtering >> criteria and rumors, is not a desirable goal. > > There is no such thing as a filtering mechanism that is 100% accurate, > and hence all are dubious to one degree or another. Fine. So please explain to me why, and under what conditions, using IP addresses as a basis for filtering is reliable. And please also explain why, and under what conditions, using DNS as a means of communicating whether a particular IP address is spamming is a good way to do that. In particular, please explain how it encourages or discourages selection of good criteria for filtering, how it enhances or degrades accountability for the party blacklisting the site (and/or the party trusting the blacklist). Explain the limitations of DNS for doing this kind of rumor mongering and how they are addressed. Explain the mechanism for reporting blacklisting errors to the parties most affected (which would include not only the senders of inappropriately filtered messages but the intended recipients of inappropriately filtered messages) and how use of DNS enhances or degrades those parties' abililty to improve their email reliability. Explain how DNS enhances or degrades a party's ability to correct both a blacklist's mislabeling of a site and a user's ability to correct his MSP's inappropriate use of a blacklist. Explain how the DNS ttl should be chosen and how it should vary on a per-domain basis. Explain the security risks associated with trusting DNS as a blacklist query protocol, and in particular what potentials exist for denial-of-service attacks and what can be done about them. See, it really appears that the design work that we would rationally expect out of any standards-track protocol has not been done in this case. It appears that large-scale use of IP addresses as identifiers for potential spammers is not well-considered, especially in an era with widespread use of NAT. It also appears that use of DNS as a query protocol is not well considered beyond the fact that such a query could be implemented by a sendmail rewrite rule. In other words, this is a hack that has gotten way out of hand. And not a particularly well-designed hack at that. > A demonstrable assertion that "IP x is demonstrably infected with > Srizbi and anything it emits is probably crap" and communicated by > DNS is much less dubious than "this combination of random content > fragments makes it look like a Nigerian 419, sorta, marginally". I'd probably agree with that statement on its face, but (a) comparing DNSBL to SA like schemes is damning DNSBL with faint praise. To my knowledge nobody has requested that IETF standardize SA, but just because SA sucks doesn't mean that DNSBL is standards-track quality even if it sucks a bit less. (b) DNSBL, in practice, doesn't actually provide anywhere near that level of assurance. It doesn't say that a host is infected with Srizbi, it just alleges that a host is bad. And in fact the alleged badness might well have been "this host sent out a combination of random content fragments that look like a Nigerian 419". Indeed, DNSBL doesn't actually say that a host is bad, it associates the badness with an IP address which might or might not be associated with the same host now as it was when the badness was observed. It doesn't say when traffic from that IP address was observed to be bad. etc. > Indeed, experience shows that a correctly chosen set of DNSBLs is often > not only more effective than other techniques in correctly identifying > malicious email, can often have far fewer false positives than just > about any other mechanism. In other words, if you make the selection the filtering criteria someone else's problem, you can pretend that the problem has gone away - even if that "someone else" is not responsible to either sender or recipient, and that "someone else" is not accountable for misrepresentation. That certainly doesn't sound like something that would pass muster for standards track. Maybe the security folks would like to comment on the sanity of extending trust to unaccountable third parties? > It certainly is counterintuitive that "source reputation" might be more > accurate than "per email evaluation". But, experience in the field > demonstrates the true reality - the current state of the art is that > intelligently chosen DNSBLs (the aforementioned BCP is intended to help > that) often work much better than complete reliance on the latter. I can accept that it makes some sense to identify compromised hosts, for instance, and that blocking mail from hosts known to be compromised with a spamming virus can in some cases be more reliable than block
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
Speaking as someone who runs their own private mail server (thunk.org), and having suffered from "collateral damage" when an entire ISP range was listed, and where I had absolutely no way of getting off a DNSBL that operating in a liability-free zone, with administrators who refused to communicate with me, and where I had no way of getting off the list, and thus had my e-mail blocked(*), forgive me if I'm a bit less sanguine than you about the suitability of DNSBL's, and whether your BCP will have any effectiveness whatsoever. If DNSBL operators are content to operate in the dark, and refuse to communicate, what makes you think they will pay attention to a BCP? (*) Fortunately in most cases it was people asking me for help with Linux, so I simply found another way to send the e-mail, and then sent them a note saying that until they switched ISP's or fixed their mail server to remove the use of the DNSBL, I would refuse to help them with their Linux ext3 problem. :-) But I view DNSBL's as fundamentally the Wrong Answer, and it breaks the intended SMTP and Internet architecture, with fundamentally wrong power dynamics. Of course, if you run a major mail operation, where DNSBL's don't dare block you lest it become obvious that the whole mechanism is corrupt, you don't see these problems. - Ted ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
John Levine wrote: >> Today, messages can just disappear on the way to the user's mailbox >> (often at or after that last-hop MTA). They do so without NDNs out >> of fear of blowback, and they do so for two main reasons. ... > You know, DNSBLs make mystery disappearances less likely, not more. > > The DNSBLs that most people use are typically checked at SMTP time, sp > MTAs can give a 5xx rejection using the TXT record from the DNSBL that > identifies why the mail was rejected. Indeed, and more concretely: NDNs aren't inherently bad (blowback). It's "accept then generate NDN" that's inherently bad. Anti-spam techniques that are after the destination's MX should not generate NDNs, because all of it is potentially blowback by definition. The "just disappear" argument more applies to techniques that can't NDN without blowback. Which, includes, for example, ALL client-side filtering no matter what filtering they use, and all server-based "accept-then-analyse" filtering. Not DNSBLs per-se. By far the most common server-based implementations using DNSBLs reject at SMTP time (usually with some sort of remediation information in the error message), which suppresses almost all blowback, yet "you" still find out what happened. In contrast, for example, the most common implementations of (say) content analysis do accept-then-analyse, and should not NDN because it'll be blowback. Full analysis during SMTP time of (say) content and rejecting at SMTP time is considerably rarer (we're one of the rarer ones). In part because older revisions of the SMTP standards weren't very clear about handling of rejections after DATA. We decided to ignore that limitation. In other words, in general you're far more likely to find out about your email not getting through (and how to fix it) if it was a DNSBL hit than most other techniques. It's not intrinsically inherent to DNSBLs, it's just the "overwhelming experience". >> Unlike you, I don't see "overwhelming community consensus for >> this mechanism". > > Aw, come on. There's a billion and a half mailboxes using the > Spamhaus DNSBLs, on systems ranging from giant ISPs down to hobbyist > Linux boxes. All of the very largest email and spam filtering infrastructures use DNSBLs (generally IP-based reputation lists) in one way or another, whether they tell you or not. I said "all" because I meant "all" - that's not hyperbole for "most". ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
Keith Moore wrote: > John Levine wrote: > >>> Unlike you, I don't see "overwhelming community consensus for >>> this mechanism". >> Aw, come on. There's a billion and a half mailboxes using the >> Spamhaus DNSBLs, on systems ranging from giant ISPs down to hobbyist >> Linux boxes. > > and there's a billion and a half users whose email is being degraded by > such mechanisms. > > if you ask them whether they want to not receive spam, they'll say yes. > if you ask them whether they want their incoming mail filtered on the > basis of unsubstantiated rumor and unreliable identifiers, they'll say no. Then you go to the next logical step, and turn Spamhaus off, and you ask them whether they want it back on. They'll say yes. They did here (the question was an accidental goof on my part that turned off Spamhaus queries, the answer (trouble tickets about spam filtering not working, despite all the other filtering mechanisms unaffected by the goof) was overwhelming) Secondly, the term "unsubstantiated rumor" - that implies that Spamhaus accepts unsubstantiated allegations from anyone. They don't. "Unsubstantiated rumor" - unsubstantiated by whom? Represented how? I'd contend that Spamhaus's listings are all substantiated by them, but no matter. PSBL, for example, substantiates every listing with a spam sample via their web site. CBL (Spamhaus XBL) entries are substantiated by SMTP transactions from the IP in question, usually with specific identification of the spambot that did it. They may not reveal precise details of their heuristics of how they detected it, nor a sample, but experience indicates that they are right virtually 100% of the time. I don't need 100% full transparency or 100% substantiation, if experience shows I can trust it. And I do. Those that represent 1 1/2 billion mail accounts trust it too. This is also that false dichotomy again: just because a DNSBL might issue "unsubstantiated rumor" doesn't mean that they ALL necessarily do. "Some A does B" != "All A does B". Indeed, I would contend that to most people, the appearance of Miriam Abacha (that will trigger some non-DNSBL-based filters) as being spam sign is unsubstantiated rumor. But that is the basis for other filtering methods. One might reply that the IETF should not standardize the insides of those methods. But who cares? They don't need consistent inter-machine protocols. DNSBLs do. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
Keith Moore wrote: > I think you're missing the point. Oh, no, I fully understand the point. In contrast, I think you're relying on false dichotomies. For example: > Better "interoperation" of a facility that degrades the reliability of > email, by encouraging an increased reliance on dubious filtering > criteria and rumors, is not a desirable goal. There is no such thing as a filtering mechanism that is 100% accurate, and hence all are dubious to one degree or another. Every technique relies upon factors that are based on intuition and experience, rather than physical law. A demonstrable assertion that "IP x is demonstrably infected with Srizbi and anything it emits is probably crap" and communicated by DNS is much less dubious than "this combination of random content fragments makes it look like a Nigerian 419, sorta, marginally". Indeed, experience shows that a correctly chosen set of DNSBLs is often not only more effective than other techniques in correctly identifying malicious email, can often have far fewer false positives than just about any other mechanism. It certainly is counterintuitive that "source reputation" might be more accurate than "per email evaluation". But, experience in the field demonstrates the true reality - the current state of the art is that intelligently chosen DNSBLs (the aforementioned BCP is intended to help that) often work much better than complete reliance on the latter. Furthermore, incorrect DNSBL listings are easier to cope with than, say, random combinations of SpamAssassin scores that just happen to zap a desirable email. This is not specific to SA. It's just as applicable to other things like Bayesian. We run DNSBLs and SpamAssassin here on the MXes. The former catches 10 times as much as the latter, FPs less, and is a lot easier to explain and remediate than the latter. We _hate_ SA FPs, because it's so much more difficult to ensure that it doesn't repeat. [The obvious Bayesian/SA remediation (whitelisting email addresses) isn't good enough. Virtually all malicious email is forged. Thus, whitelisting senders leaves you wide open to getting zapped by forgeries.] > Even assuming that there's some benefit in having third-party reputation > services (which IMHO is not well-established), Again, a false dichotomy: DNSBLs are not necessarily third-party, and other perfectly reputable techniques (eg: outsourcing your spam filtering to a spam filtering company or relying on your ISPs filtering) are third party by definition. Indeed, running your own copy of SpamAssassin on your own mail box is just as much giving away "control" of your filtering to a third party with their own evaluations techniques of greater or lesser dubiousness. Is it not third party because you can tweak the rules of SA? You can also locally whitelist around DNSBL entries. The only way you can get away from "third party" is to write your own filters from scratch, and ignore everybody else's heuristics. I generate several DNSBLs for use here only. Why shouldn't there be a standard so that mail server software I buy/lease/license will interoperate with DNSBLs I create? "Not well-established"? You don't seem to have any idea how prevalent the use of DNSBLs is. It's probably the industry's dirty little secret because of the occasional media event. But there have been similar media events about other filtering techniques that aren't 3rd party, nor source reputation. The reality is: almost everybody uses DNSBLs, and ALL of the very big sites do. > use of DNS to communicate > such reputation, and basing such reputation on IP addresses, is itself > very dubious. You may think it dubious, but it is usually more reliable and effective than any other, and its popularity alone means it needs to be standardized. Rejecting the standardization of DNSBL protocols because the entries of a specific DNSBL _might_ be dubious is in itself a dubious position. > The problem isn't just the rumor passing mechanism, but > the mechanism is indeed part of the problem. > > It's not as if we're arguing about whether to standardize a facility > that is widely believed to work well. It is widely believed to work well. That's part of the point. > We're arguing about whether to > standardize a facility that causes problems for everyone. No more so than filtering in general. > Back when I started working with email, getting a message reliably > delivered was something of a black art, because you had to know how to > thread your message through the hodgepodge of Internet, uucp, BITNET, > DECnet, fidonet, and whatnot. That was in some sense understandable > because Internet access was not widely available, and there wasn't > really any common network that everybody could tap into. > > Today, getting a message reliably delivered is once again a black art. > But today, it's not for lack of standards or network connectivity. It's > because so many messages are filtered for dubious reasons, or on
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
Keith Moore wrote: Today, getting a message reliably delivered is once again a black art. But today, it's not for lack of standards or network connectivity. It's because so many messages are filtered for dubious reasons, or on the basis of what are essentially unsubstantiated rumors, or because of over-reliance on IP source addresses as identifiers. Several years ago, my employer's e-mail spam filter blocked the Unicode mailing list as a "suspect site." Earlier this year, GoDaddy (registrar of my domain name) did the same, and it took months to figure out what was going on. It's conceivable that someone might have used this high-profile mailing list as part of a spam, at some point, but to block the entire domain is complete overkill. I'm no expert on e-mail security, and I detest spam, but there is such a thing as a cure that is worse than the disease. -- Doug Ewell * Thornton, Colorado, USA * RFC 4645 * UTN #14 http://www.ewellic.org http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages ˆ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
Sometimes, people say "this shouldn't even be an Informational RFC because people can't tell the difference between the types of RFCs and they'll think the IETF supports the technology". Sometimes, people say "this shouldn't be a standards-track RFC but it is OK for it to be an Informational RFC because people notice the difference and think the difference is important". Sometimes, those are the same people talking about different documents. The IETF has repeatedly tried and failed to fix the "RFC levels" problem. It is absurd to have the debate repeatedly and try to hold documents to one temporary belief or the other. Unless we fix the RFC levels problem, we can only rely on the content of the document itself. To my reading, this document does not promote the use of blacklists, much less of crappy blacklists (of which I am an erroneous target). The text seems to be all about bits-on-the-wire interoperability that affects large and small ISPs. --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
John Levine wrote: >> Unlike you, I don't see "overwhelming community consensus for >> this mechanism". > > Aw, come on. There's a billion and a half mailboxes using the > Spamhaus DNSBLs, on systems ranging from giant ISPs down to hobbyist > Linux boxes. and there's a billion and a half users whose email is being degraded by such mechanisms. if you ask them whether they want to not receive spam, they'll say yes. if you ask them whether they want their incoming mail filtered on the basis of unsubstantiated rumor and unreliable identifiers, they'll say no. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
I think you're missing the point. Better "interoperation" of a facility that degrades the reliability of email, by encouraging an increased reliance on dubious filtering criteria and rumors, is not a desirable goal. Even assuming that there's some benefit in having third-party reputation services (which IMHO is not well-established), use of DNS to communicate such reputation, and basing such reputation on IP addresses, is itself very dubious. The problem isn't just the rumor passing mechanism, but the mechanism is indeed part of the problem. It's not as if we're arguing about whether to standardize a facility that is widely believed to work well. We're arguing about whether to standardize a facility that causes problems for everyone. Back when I started working with email, getting a message reliably delivered was something of a black art, because you had to know how to thread your message through the hodgepodge of Internet, uucp, BITNET, DECnet, fidonet, and whatnot. That was in some sense understandable because Internet access was not widely available, and there wasn't really any common network that everybody could tap into. Today, getting a message reliably delivered is once again a black art. But today, it's not for lack of standards or network connectivity. It's because so many messages are filtered for dubious reasons, or on the basis of what are essentially unsubstantiated rumors, or because of over-reliance on IP source addresses as identifiers. Keith Chris Lewis wrote: > As the architect of a large email infrastructure, a senior technical > advisor to the Mail Anti-Abuse Working Group, and ASRG member, I find > myself disagreeing with the points made by John and Keith that I > included at the end. > > As a consumer (and producer) of DNSBLs, I need technical standards that > define DNSBL protocol so I can spec/build/acquire/use software that > interoperates correctly and maintains/improves the reliability of our > email and email in general. > > I also want policy predictability in the DNSBLs I use or am likely to > encounter when our users send email, but that does not belong in a DNSBL > technical standard on protocols. It belongs in a different document. > More below. > > Yes, the very existence of DNSBLs is unfortunate, but they have become > an outright necessity for many mail systems. Our (and many other, > including all of very largest) mail infrastructures heavily rely on > DNSBLs for the majority of their filtering. No other filtering > technique deals as effectively with the massive floods of spam and other > malicious content that we receive (in some cases well in excess of 90% > of all email). > > Yes, some people honestly believe that the use of DNSBLs for blocking is > a bad idea. But those objections fall away when they're used in > aggregate scoring systems like SpamAssassin, where they're just one > minor factor of many. DNSBLs need to be standardized, whether they > block an email, tweak a score a bit like SpamAssassin, or as in some > environments, improve an email's likelihood of getting through (eg: > whitelists). > > There are many advanced non-DNSBL techniques that can and do work well > in place of DNSBLs on small to medium systems. Unfortunately, they are > either considerably less ineffective or are impractical in large to very > large systems trying to withstand the full spectrum of email abuse that > they have to deal with daily. DNSBLs (locally sourced or otherwise) > often make the difference between email remaining useable or becoming > unuseable in environments like ours. > > It is but one tool of many tools. Yet, for many infrastructures, by far > the most effective. Virtually every major email system uses DNSBLs in > one way or another, whether it's visible or not, whether it's used > directly by themselves, or in concert with other mechanisms (eg: scoring). > > Failing to standardize the technical protocols used by them would be a > major mistake. > > More specific points: > > 1) There are no technical omissions in the specification that I am aware > of. It is a technical specification of the bits on the wire (the > protocol), with little else. > > 2) I presume the "technical omissions" comment was intended to mean a > lack of standardization of "how things got on and off DNSBLs". These > are not, and should not, be considered technical issues. Specifying how > something got on and off a DNSBL would be equivalent to insisting that > RFC2822 attempt to standardize how mail readers insert an email address > in the To header. RFC2822 specifies the format of To headers, not how > they got there. > > Yes, there are issues about such things, and consistency in some of > these areas is desired. But, they do not belong in a technical > standard. 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-blac
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
>Today, messages can just disappear on the way to the user's mailbox >(often at or after that last-hop MTA). They do so without NDNs out >of fear of blowback, and they do so for two main reasons. ... You know, DNSBLs make mystery disappearances less likely, not more. The DNSBLs that most people use are typically checked at SMTP time, sp MTAs can give a 5xx rejection using the TXT record from the DNSBL that identifies why the mail was rejected. Even if the DNSBL isn't in the rejection message, there aren't that many lists that are widely enough used to matter, and since DNSBL listings (unlike the private per-system blacklists that are the most likely alternative) are by their nature public, it is easy enough to check a bunch of them and see if you're on one of them, thereby identifying the problem. The other approach is to use them in a scoring filter, but they'll do what they do whether or not they mix DNSBLs into the score. >Unlike you, I don't see "overwhelming community consensus for >this mechanism". Aw, come on. There's a billion and a half mailboxes using the Spamhaus DNSBLs, on systems ranging from giant ISPs down to hobbyist Linux boxes. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
As the architect of a large email infrastructure, a senior technical advisor to the Mail Anti-Abuse Working Group, and ASRG member, I find myself disagreeing with the points made by John and Keith that I included at the end. As a consumer (and producer) of DNSBLs, I need technical standards that define DNSBL protocol so I can spec/build/acquire/use software that interoperates correctly and maintains/improves the reliability of our email and email in general. I also want policy predictability in the DNSBLs I use or am likely to encounter when our users send email, but that does not belong in a DNSBL technical standard on protocols. It belongs in a different document. More below. Yes, the very existence of DNSBLs is unfortunate, but they have become an outright necessity for many mail systems. Our (and many other, including all of very largest) mail infrastructures heavily rely on DNSBLs for the majority of their filtering. No other filtering technique deals as effectively with the massive floods of spam and other malicious content that we receive (in some cases well in excess of 90% of all email). Yes, some people honestly believe that the use of DNSBLs for blocking is a bad idea. But those objections fall away when they're used in aggregate scoring systems like SpamAssassin, where they're just one minor factor of many. DNSBLs need to be standardized, whether they block an email, tweak a score a bit like SpamAssassin, or as in some environments, improve an email's likelihood of getting through (eg: whitelists). There are many advanced non-DNSBL techniques that can and do work well in place of DNSBLs on small to medium systems. Unfortunately, they are either considerably less ineffective or are impractical in large to very large systems trying to withstand the full spectrum of email abuse that they have to deal with daily. DNSBLs (locally sourced or otherwise) often make the difference between email remaining useable or becoming unuseable in environments like ours. It is but one tool of many tools. Yet, for many infrastructures, by far the most effective. Virtually every major email system uses DNSBLs in one way or another, whether it's visible or not, whether it's used directly by themselves, or in concert with other mechanisms (eg: scoring). Failing to standardize the technical protocols used by them would be a major mistake. More specific points: 1) There are no technical omissions in the specification that I am aware of. It is a technical specification of the bits on the wire (the protocol), with little else. 2) I presume the "technical omissions" comment was intended to mean a lack of standardization of "how things got on and off DNSBLs". These are not, and should not, be considered technical issues. Specifying how something got on and off a DNSBL would be equivalent to insisting that RFC2822 attempt to standardize how mail readers insert an email address in the To header. RFC2822 specifies the format of To headers, not how they got there. Yes, there are issues about such things, and consistency in some of these areas is desired. But, they do not belong in a technical standard. 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. 3) Making draft-irtf-asrg-dnsbl a standard (and ultimately approving the BCP) serves to improve the consistency and interoperability of DNSBLs, and therefore email itself. Not making it a standard only perpetuates uncertainty on the protocol itself, failure to implement software that interoperates correctly, unpredictable (and some times capricious) failure modes, and ultimately impairs the reliability of email. Case in point: If a DNSBL domain becomes unregistered, and is picked up by a reseller, they usually insert DNS A record wildcards causing web queries to go to a common web page. Or if a DNSBL domain is mispelled by its users, it may collide with a different domain that wildcards A records. Such scenarios aren't rare, they happen frequently. Without this standardization, the implementors of DNSBL clients don't realize that DNSBL queries that return A records outside of 127/8 is an error condition not a positive result. Such mail servers usually end up blocking ALL of their email - concrete examples of where lack of standardization drastically impairs email interoperability. John C Klensin wrote: > Sadly, I have to agree with Keith. While these lists are a > fact of life today, and I would favor an informational document > or document that simply describes how they work and the issues > they raise, standardizing them and formally recommending their > use is not desirable at least without some major changes in our > email model and standards for what gets addresses on
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
John C Klensin wrote: > I'm am beginning to wish for the days at which, at least in > principle, we could standardize something and immediately put a > "not recommended" label on it. Well, I have often wished we had a clear label (or maybe even a separate document series) for things of the form "if you're going to implement this dubious idea, please do it this way because it appears to be less harmful than other ways." But we don't have one of those yet. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
--On Saturday, 08 November, 2008 12:31 -0500 Keith Moore <[EMAIL PROTECTED]> wrote: > John Levine wrote: >>> standardizing them and formally recommending their use >> >> I'm not aware of any language in the current draft that >> recommends that people use DNSBLs. > > Standardizing it is an implicit recommendation. In particular > it's a statement that there are "no known technical omissions" > about the protocol. Which is not an accurate description of > the protocol at hand. I'm am beginning to wish for the days at which, at least in principle, we could standardize something and immediately put a "not recommended" label on it. I agree with John and Dave that having an agreed-upon specification for how to do these things if one insists on doing them would be a good idea. I'm just concerned about the implication of encouragement to do it, at least without much stronger Security and Operational considerations material than is now present (and, Dave, that isn't a vague "don't like it" complaint -- it is a reference to my earlier note, Keith's notes, ekr's notes, etc.). john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
--On Saturday, 08 November, 2008 07:53 -0800 Dave CROCKER <[EMAIL PROTECTED]> wrote: > John C Klensin wrote: >> Sadly, I have to agree with Keith. While these lists are a >> fact of life today, and I would favor an informational >> document or document that simply describes how they work and >> the issues they raise, standardizing them and formally >> recommending their use is not desirable at least without some >> major changes in our email model and standards for what gets >> addresses onto --and, more important, off of-- those lists. > > > John, > > What are the technical deficiencies of this specification? Dave, Sorry if my note was incomplete. I've halfway around the world, trying to focus on something else and thought that the issue Keith raised were clear enough that they didn't require an in-depth explanation. Ekr's comment reinforces that view. However... Our email model assumes that messages that are sent either get delivered or that the sender gets an NDN back. We have never had a culture of receipts for delivery to what SMTP thinks of as the last-hop MTA, much less delivery to the user's mailbox. Today, messages can just disappear on the way to the user's mailbox (often at or after that last-hop MTA). They do so without NDNs out of fear of blowback, and they do so for two main reasons. One has to do with analysis of message content for patterns consistent with spam, the other has to with various address and domain blacklisting techniques. The problem with the latter is that it is extremely subject to abuse, both intentional and unintentional. One variation on the former has involved a DoS attack against a particular domain by used that domain in faked addresses in spam. That problem is worsened by operational difficulties in getting off the lists once one has been classified onto them, a problem exacerbated by "guilty until proven innocent using standards of proof that are unclear" that is built into the operational systems. In theory, we could address this problem by writing a Security Considerations section that includes "deployment and use of this mechanism, even by others, undermines the assumption that mail will either be delivered or NDNs produced and delivered to you and neither you nor the final recipient will necessarily have control over the mechanisms and decisions in use". But that raises issues that are quite similar to the "decision-making middlebox not controlled from either endpoint" issue as well as opening up the issue of whether we need to change the mail model to be more strongly based on delivery confirmations. FWIW, Security / Operational Considerations like that have been considered more than adequate to block standardizion... and are "known technical defects" relative to successful interoperation with existing and established protocols and models. > What are the specific problems the mechanism it defines pose > to "our email model and standards"? See above. > What are the specific, "major changes" that would be required > to the model and standards, to make the current specification > acceptable? Again, see above. > This type of mechanism has massive adoption throughput the > Internet. It's perceived efficacy also is massive. The > current specification merely seeks to provide a stable > technical basis for that mechanism. Another part of the traditional mail model is that any legitimate actor ought to be able to run his or her own mail server. I suspect, based on what is now a fairly large, although opportunistic, sample, that a very large fraction of those who are running a mail server on less than a T1/E1 link, in PD space, and with mail system volume several orders of magnitude smaller than that of AOL/ Gmail/ Hotmail/ Yahoo have been burned at least once or twice by these mailing lists. That implies that these methods are reducing the reliability and predictability of the email system, which is exactly what Keith said and, again, is a reason to not standardize. > In the face of overwhelming community consensus for this > mechanism, you offer a simple, flat, fundamental rejection, > yet provide no substantiation. Unlike you, I don't see "overwhelming community consensus for this mechanism". There is probably consensus among those for whom mail system reliability in terms of delivery of legitimate messages is less important than deleting spam, and especially among those whose mail operations are large enough that they will never find themselves blacklisted (although I vaguely remember an incident in which some outgoing Gmail addresses ended up on a blacklist). But there is no consensus at all among those of us who see this sort of technique as operationally dangerous and problematic... so much so as to call its value into question. > Really, John, it would help for a posting to do more than say > that you don't like the idea of the mechanism. I don't think that characterization of what I (or Keith) said is fair. I also don't th
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
At Sat, 08 Nov 2008 08:53:36 -0800, Dave CROCKER wrote: > > > > Eric Rescorla wrote: > > Speaking as someone who just got burned by exactly such a list, > > I think I need to agree with John: I don't object to the IETF > > publishing an informational document on this, but a PS implies > > that IETF endorses the practice, which I don't think we should do. > > > Eric, > > Roughly 95% of all mail is spam. That makes email a pretty onerous > "practice". > > So we ought to remove standards status for all email specifications. I don't think this follows from my comment. > Or we could consider keeping mechanism and policy separate, standardizing > technologies (mechanisms) and refraining from condemning them because some > operators have misguided policies and use the mechanisms badly. This sounds like a false choice to me. > Really, guys, everything we standardize has examples of misuse. So that > hardly > makes your current line of argument substantive. You're certainly welcome to have that opinion, but I don't think that's what I'm saying. For the reasons Keith is suggesting, among others, I don't think this is a very good mechanism and therefore the IETF shouldn't endorse it. As I said, I don't have a problem with this document being advanced as Informational, but PS is different. -Ekr ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
John Levine wrote: >> standardizing them and formally recommending their use > > I'm not aware of any language in the current draft that recommends > that people use DNSBLs. Standardizing it is an implicit recommendation. In particular it's a statement that there are "no known technical omissions" about the protocol. Which is not an accurate description of the protocol at hand. What it does say is that if you use or > publish DNSBLs, here's how they work so you can, you know, > interoperate and all that. As I'm sure everyone is aware, there are > large numbers of independently written implementations, both > publishers and users of DNSBLs, so they seem ripe to me for > standardization. So there's a clear justification for an Informational document describing current practice - and also what's wrong with it. Widespread deployment is not a justification for standardization. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
On 8 Nov 2008 17:05:00 - John Levine <[EMAIL PROTECTED]> wrote: > > standardizing them and formally recommending their use > > I'm not aware of any language in the current draft that recommends > that people use DNSBLs. What it does say is that if you use or > publish DNSBLs, here's how they work so you can, you know, > interoperate and all that. I hear you -- but http://xkcd.com/463/ comes to mind. --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
> standardizing them and formally recommending their use I'm not aware of any language in the current draft that recommends that people use DNSBLs. What it does say is that if you use or publish DNSBLs, here's how they work so you can, you know, interoperate and all that. As I'm sure everyone is aware, there are large numbers of independently written implementations, both publishers and users of DNSBLs, so they seem ripe to me for standardization. > standards for what gets addresses onto --and, more important, off > of-- those lists. Some other people are working on a separate document codifying best practices based on the experience of both people who run widely used highly accurate DNSBLs and operators of large mail systems that use them. It should come along in the next month or so and might be BCP or Informational. But I have to say I am concerned that it will be picked to death by people whose opinions of DNSBLs haven't been reexamined since they were formed based on anecdotes in the late 1990s. If you want to start picking now, feel free to do so on the ASRG list. For links see http://wiki.asrg.sp.am R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
Dave, you're mischaracterizing the situation and you ought to know better. basing reputation on IP address is pretty dubious. transmitting reputation over DNS is not "otherwise-acceptable" and there's at least some argument to be made that this choice of mechanism lends itself to abuse, or even encourages it. and it appears that there's considerably less than rough consensus in favor of DNSBLs ... especially if you ask people whose mail has been blocked because of them. Keith > Eric, > > Roughly 95% of all mail is spam. That makes email a pretty onerous > "practice". > > So we ought to remove standards status for all email specifications. > > Or we could consider keeping mechanism and policy separate, > standardizing technologies (mechanisms) and refraining from condemning > them because some operators have misguided policies and use the > mechanisms badly. > > Really, guys, everything we standardize has examples of misuse. So that > hardly makes your current line of argument substantive. > > Are you actually saying that there is something inherently inappropriate > in having published reputation lists and that a technical standards body > like the IETF is tasked with rejecting standardization of > otherwise-acceptable technical specifications because we don't like how > some people will use them? > > Are you seriously lobbying for the IETF to be an idealistic island that > ignores rough consensus and very well-established practice among the > broader Internet community? > > d/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
Eric Rescorla wrote: Speaking as someone who just got burned by exactly such a list, I think I need to agree with John: I don't object to the IETF publishing an informational document on this, but a PS implies that IETF endorses the practice, which I don't think we should do. Eric, Roughly 95% of all mail is spam. That makes email a pretty onerous "practice". So we ought to remove standards status for all email specifications. Or we could consider keeping mechanism and policy separate, standardizing technologies (mechanisms) and refraining from condemning them because some operators have misguided policies and use the mechanisms badly. Really, guys, everything we standardize has examples of misuse. So that hardly makes your current line of argument substantive. Are you actually saying that there is something inherently inappropriate in having published reputation lists and that a technical standards body like the IETF is tasked with rejecting standardization of otherwise-acceptable technical specifications because we don't like how some people will use them? Are you seriously lobbying for the IETF to be an idealistic island that ignores rough consensus and very well-established practice among the broader Internet community? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
Ned Freed wrote: >> Sadly, I have to agree with Keith. While these lists are a >> fact of life today, and I would favor an informational document >> or document that simply describes how they work and the issues >> they raise, standardizing them and formally recommending their >> use is not desirable at least without some major changes in our >> email model and standards for what gets addresses onto --and, >> more important, off of-- those lists. > > Such a criticism might be a sensible response to a document that defines an > actual whitelisting or blacklisting service. But that's not what this document > does. Rather, this document defines vaarious formats for storing such > information in the DNS and procedures for querying that data. Specification of > actual services based on these formats and procedures is left for later > specifications. > > Standardizing these formats and procedures is important for at least two > reasons: (1) Without a specification nailing down these details there can be > (and in practice have been) interoperability problems between various > implementations and (2) Without something describing how to structure and > operate these systems they can, independent of the actual list content, create > serious operational problems. I could almost buy this argument. The reasons I don't buy it in this case are: (1) using the IP source address as an indicator of any kind of identity has been dubious for a long time (even in an enterprise network, but especially in the Internet at large), and it is only going to get more dubious in an era of IPv4/IPv6 transition where IPv4 addresses are shared between different entities. (2) use of DNS to communicate this information is a stretch at best. the protocol is too constrained, and not designed for a use case like this where the information that needs to be conveyed is very short-lived in nature. (3) the security considerations associated with such use, including considerations for denial-of-service attack, are quite difficult to address. so I think there's a compelling case to be made that any kind of DNSBL is a poor design not worthy of standardization. > Now, I am of course aware of the line of reasoning that says we should not > publish specifications for things that can potentially be abused. I'm sorry, > but if we take a candid look at how this strategy has played out with other > technologies ranging from MIME downgrading to NAT to Bonjour, I think the > record is fairly clear: We're much better off specifying things while calling > out the dangers of their use than we are when we all run off out our > respective > corners and pout about the sad state of the world. I don't think the examples you cite demonstrate that. Standardizing NATs in the 1990s would not have helped because the widespread assumptions at that time were that you couldn't really change NAT behavior and that the NATs had to operate "transparently" to the applications. Even today we still don't know how to make a NAT that works well, without making the endpoints aware of the NAT, and giving them explicit control over bindings. As for Bonjour, I at least did try to call out dangers of the use of IPv4 linklocal addresses, and with overloading DNS names and APIs, and the WG repeatedly, stubbornly denied that those dangers existed and continued to do so until IESG pushed back on at least some of those points. But of course the question is not whether something like this can be abused - anything can be abused. The question is whether something like this encourages abuse, or if not deliberate abuse, whether it encourages degraded reliability of the email system. And I think there's a fair amount of empirical evidence that it does. That doesn't mean that we shouldn't try to design a better system for identifying and reporting sources of spam or viruses. But to me it seems entirely plausible that relying on DNS to transmit this information is part of the reason that DNSBLs are so often associated with abuse and denial-of-service attack. If we were designing such a system from scratch we'd naturally be concerned about things like accountability, repeatability, polling intervals, and identifying the precise criteria used to blacklist an address. We'd probably want to expose more information to the client about why a site was blacklisted, when it was blacklisted, and so forth, so that the client wouldn't be bouncing mail without a good reason. But trying to shoehorn this kind of service into DNS forces most of these considerations to be overlooked simply because there's not a good way to communicate them in DNS. Really what this document is trying to do is to standardize a crude hack - as well as being a blatant attempt at an end-run around our concensus processes. Publishing it as informational, with appropriate caveats about the inherent limitations of the approach (including security considerations) could be beneficial. But I can't see how the prot
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
At Sat, 08 Nov 2008 06:46:54 -0500, John C Klensin wrote: > > Sadly, I have to agree with Keith. While these lists are a > fact of life today, and I would favor an informational document > or document that simply describes how they work and the issues > they raise, standardizing them and formally recommending their > use is not desirable at least without some major changes in our > email model and standards for what gets addresses onto --and, > more important, off of-- those lists. Speaking as someone who just got burned by exactly such a list, I think I need to agree with John: I don't object to the IETF publishing an informational document on this, but a PS implies that IETF endorses the practice, which I don't think we should do. I appreciate that there is a fine distinction here, but it seems to me that it's precisely for cases like this where the distinction is appropriate. -Ekr ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
John C Klensin wrote: Sadly, I have to agree with Keith. While these lists are a fact of life today, and I would favor an informational document or document that simply describes how they work and the issues they raise, standardizing them and formally recommending their use is not desirable at least without some major changes in our email model and standards for what gets addresses onto --and, more important, off of-- those lists. John, What are the technical deficiencies of this specification? What are the specific problems the mechanism it defines pose to "our email model and standards"? What are the specific, "major changes" that would be required to the model and standards, to make the current specification acceptable? This type of mechanism has massive adoption throughput the Internet. It's perceived efficacy also is massive. The current specification merely seeks to provide a stable technical basis for that mechanism. In the face of overwhelming community consensus for this mechanism, you offer a simple, flat, fundamental rejection, yet provide no substantiation. Really, John, it would help for a posting to do more than say that you don't like the idea of the mechanism. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
> Sadly, I have to agree with Keith. While these lists are a > fact of life today, and I would favor an informational document > or document that simply describes how they work and the issues > they raise, standardizing them and formally recommending their > use is not desirable at least without some major changes in our > email model and standards for what gets addresses onto --and, > more important, off of-- those lists. Such a criticism might be a sensible response to a document that defines an actual whitelisting or blacklisting service. But that's not what this document does. Rather, this document defines vaarious formats for storing such information in the DNS and procedures for querying that data. Specification of actual services based on these formats and procedures is left for later specifications. Standardizing these formats and procedures is important for at least two reasons: (1) Without a specification nailing down these details there can be (and in practice have been) interoperability problems between various implementations and (2) Without something describing how to structure and operate these systems they can, independent of the actual list content, create serious operational problems. Now, I am of course aware of the line of reasoning that says we should not publish specifications for things that can potentially be abused. I'm sorry, but if we take a candid look at how this strategy has played out with other technologies ranging from MIME downgrading to NAT to Bonjour, I think the record is fairly clear: We're much better off specifying things while calling out the dangers of their use than we are when we all run off out our respective corners and pout about the sad state of the world. Assuming that the document does in fact define sensible formats that can be operated at Internet scale (I think it does but am willing to be shown otherwise by those with more expertise in large-scale DNS operations than I have) and does not preclude operating a reliable and accountable service (again, I think it does but I am willing to be proved wrong with specific examples), I support publication of this specification. Ned ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
Sadly, I have to agree with Keith. While these lists are a fact of life today, and I would favor an informational document or document that simply describes how they work and the issues they raise, standardizing them and formally recommending their use is not desirable at least without some major changes in our email model and standards for what gets addresses onto --and, more important, off of-- those lists. john --On Friday, 07 November, 2008 18:38 -0500 Keith Moore <[EMAIL PROTECTED]> wrote: > DNSBLs work to degrade the interoperability of email, to make > its delivery less reliable and system less accountable for > failures. They do NOT meet the "no known technical omissions" > criterion required of standards-track documents. > > The fact that they are widely used is sad, not a justification > for standardization. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
DNSBLs work to degrade the interoperability of email, to make its delivery less reliable and system less accountable for failures. They do NOT meet the "no known technical omissions" criterion required of standards-track documents. The fact that they are widely used is sad, not a justification for standardization. > > As an operator of a large mail domain, I'd like to reiterate John's > comments above. DNSBLs work, are very cost (and computationally) > effective, and are in widespread use. > > Regards > Jason > ___ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
