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 toward
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.
> >> >
>
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 liste
* 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
* 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 re
>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
suite
* 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 generate
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 usi
* 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 p
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
* 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 sh
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,
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 an
"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 e
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:
vari
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 d
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
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.
>
>
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/
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 ev
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,
>
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
m
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
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 th
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 st
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
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 p
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 I
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 nega
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
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 effectiv
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
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 co
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
> 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.
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 al
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.
>
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
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 entr
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 maint
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
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.
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 d
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
[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 ne
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 O
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 DNSB
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
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
> -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
> 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
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 fro
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 wa
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,
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
> 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 sup
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
[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
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 m
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
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,
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 c
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 whiteli
> 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 th
-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 ha
--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 pro
--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 figur
--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 submiss
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
>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
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 im
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.
Kei
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 a
>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? The
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 encouragin
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
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.
>
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'
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 f
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
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 RF
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
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
>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
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
d
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
--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 im
--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
>
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 I
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 omissio
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
> 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
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
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
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 desir
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 formall
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 a
> 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
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
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 fo
1 - 100 of 109 matches
Mail list logo
