Re: Context specific semantics was Re: uncooperative DNSBLs, was several messages

Seriously, it's not obvious to me that it's *impossible* to change. Of course it's not impossible. But the question is whether the benefit from the change is large enough that the people who'd have to write the software will do so. IPv4 DNSBLs have been working just dandy with A records for

Re: more bad ideas, was uncooperative DNSBLs, was several messages

John Levine wrote: >> For instance, what would happen if mail servers provided feedback to >> both senders (on a per message basis in the form of NDNs) > > Well, since 95% of all mail is spam, and all the spam has fake return > addresses, you'd increase the amount of bogus NDNs by more than an > o

Re: more bad ideas, was uncooperative DNSBLs, was several messages

>For instance, what would happen if mail servers provided feedback to >both senders (on a per message basis in the form of NDNs) Well, since 95% of all mail is spam, and all the spam has fake return addresses, you'd increase the amount of bogus NDNs by more than an order of magnitude. No thanks.

Re: uncooperative DNSBLs, IETF misinformation (was: several messages)

Theodore Tso wrote: > I would also encourage the "how to run a DNSBL responsibly" to be > published at the same time, so that draft-irtf-asrg-dnsbl could > reference the "this is how you do it right" (while acknowledging the > only out of band mechanisms can be used to ensure that a DNSBL > operat

Re: Context specific semantics was Re: uncooperative DNSBLs, was several messages

On Fri, Nov 14, 2008 at 01:38:54PM -0800, Ted Hardie wrote: > If we are documenting practice and nothing more, then the publication > stream can move to informational and text can be added on why > a new RR, which would normally be expected here, is not being used > (essentially, inertia in the fac

Re: uncooperative DNSBLs, IETF misinformation (was: several messages)

On Fri, Nov 14, 2008 at 04:08:50PM -0500, Al Iverson wrote: > >> Is this unique to DNSBLs? If not, then why does it merit deeper > >> consideration in the context of DNSBLs? > > > > what you are arguing is that rather than trying to address the harm done > > by DNSBLs, IETF should ignore that harm

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 sh

Re: Context specific semantics was Re: uncooperative DNSBLs, was several messages

On Nov 14, 2008, at 1:38 PM, Ted Hardie wrote: If we are documenting practice and nothing more, then the publication stream can move to informational and text can be added on why a new RR, which would normally be expected here, is not being used (essentially, inertia in the face of 15 year

Re: Context specific semantics was Re: uncooperative DNSBLs, was several messages

At 10:56 AM -0800 11/14/08, John L wrote: > > Sorry, what about SRV made RRTYPE not significant? Sorry >> to be dense, but I don't understand your point here. > >A SRV record with _tcp in its name means something different from a SRV >query with _udp in its name. I suppose you could argue that's

Re: uncooperative DNSBLs, IETF misinformation (was: several messages)

On Fri, Nov 14, 2008 at 3:01 PM, Keith Moore <[EMAIL PROTECTED]> wrote: > Al Iverson wrote: > >> Is this unique to DNSBLs? If not, then why does it merit deeper >> consideration in the context of DNSBLs? > > what you are arguing is that rather than trying to address the harm done > by DNSBLs, IETF

RE: several messages

> Although this one has been, IMO, a little more hostile than > necessary (on both sides), anyone who isn't interested in > that type of review should not be looking for IETF Standardization. And for those who have not read the Tao of IETF, the relevant section is 8.2. Letting Go Gracefully

Re: several messages

On Fri, Nov 14, 2008 at 2:50 PM, John C Klensin <[EMAIL PROTECTED]> wrote: > > > --On Friday, 14 November, 2008 13:51 -0500 Al Iverson > <[EMAIL PROTECTED]> wrote: > >>... >> This strikes me as unrelated to DNSBLs. Am I misunderstanding? >> How is this DNSBL-specific? > > Al, and others, > > While

Re: uncooperative DNSBLs, IETF misinformation (was: several messages)

Al Iverson wrote: > Is this unique to DNSBLs? If not, then why does it merit deeper > consideration in the context of DNSBLs? what you are arguing is that rather than trying to address the harm done by DNSBLs, IETF should ignore that harm by ruling it out of scope for the current discussion. ___

Re: several messages

John C Klensin wrote: > Sigh. > > Rich, you can blame "someone else" all you like, but the reality > here is that > > (1) If the system supporting the DNSBL is following the email > protocols and decides to reject the message or bounce it, rather > than, e.g., assigning a score and moving it in

Re: several messages

--On Friday, 14 November, 2008 13:51 -0500 Al Iverson <[EMAIL PROTECTED]> wrote: >... > This strikes me as unrelated to DNSBLs. Am I misunderstanding? > How is this DNSBL-specific? Al, and others, While many of us are less opposed to DNSBLs in principle than you or your colleagues may be assum

RE: uncooperative DNSBLs, IETF misinformation (was: several messages)

> > A user writes an email and sends it to another user. The other user > > does not receive the email. This means that deliverability > is broken. > > The DNSBL is an agent in preventing that delivery. > > Is this unique to DNSBLs? If not, then why does it merit > deeper consideration in the

Re: uncooperative DNSBLs, IETF misinformation (was: several messages)

On Fri, Nov 14, 2008 at 1:59 PM, <[EMAIL PROTECTED]> wrote: Thanks, appreciate the insight. >> > This still breaks deliverability. >> >> How? > > A user writes an email and sends it to another user. The other user does > not receive the email. This means that deliverability is broken. The > DNSB

RE: uncooperative DNSBLs, IETF misinformation (was: several messages)

> > This still breaks deliverability. > > How? A user writes an email and sends it to another user. The other user does not receive the email. This means that deliverability is broken. The DNSBL is an agent in preventing that delivery. To my mind, this deserves some explicit discussion in the Sec

Re: Context specific semantics was Re: uncooperative DNSBLs, was several messages

context for the RRTYPE based on the zone of the query, which is not what the DNS currently uses for disambiguating the types of requests/responses. Didn't that plan go out the window in 1996 with RFC 2052? Sorry, what about SRV made RRTYPE not significant? Sorry to be dense, but I don't under

Re: several messages

On Fri, Nov 14, 2008 at 1:45 PM, John C Klensin <[EMAIL PROTECTED]> wrote: > > > --On Thursday, 13 November, 2008 11:56 -0500 Rich Kulawiec > <[EMAIL PROTECTED]> wrote: > >> On Wed, Nov 12, 2008 at 11:33:46AM -0800, Randy Presuhn wrote: >>> Huh? Concrete, real example: I send a message to an IETF

Re: several messages

--On Thursday, 13 November, 2008 11:56 -0500 Rich Kulawiec <[EMAIL PROTECTED]> wrote: > On Wed, Nov 12, 2008 at 11:33:46AM -0800, Randy Presuhn wrote: >> Huh? Concrete, real example: I send a message to an IETF >> mailing list. A list subscriber's ISP rejects the forwarded >> message. IETF's

Re: Who Wants an RFID Badge for the Upcoming IETF Conference?

We've thought about the blue sheet replacement, but wanted to start a bit smaller and reduce the impact of failure. (With the current experiment, presumably the worst-case outcome is no worse than what we've had for the past 70+ IETFs, but losing blue sheet information might make some lawye

Gen-ART Review of draft-ietf-smime-sha2-09.txt

I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-smime

Re: FTP to HISTORIC? RE: [BEHAVE] Can we have on NAT66 discussion?

At 08:43 14-11-2008, Hallam-Baker, Phillip wrote: I propose that we either move FTP to historic or start a revision effort if there is sufficient interest in continuing it as a separate protocol from HTTP. There are a few I-D about FTP that have been submitted: FTP Extension Registry http://w

Re: FTP to HISTORIC? RE: [BEHAVE] Can we have on NAT66 discussion?

Hallam-Baker, Phillip wrote: > The Internet has two protocols that account for >95% of user > interactions, email and Web. Pointing out that one of those protocols > involves an IP address change en-route might be a single data point but > it is a significant one. it's a fallacy that you can measu

RE: Context specific semantics was Re: uncooperative DNSBLs, was several messages

At 8:17 AM -0800 11/14/08, Tony Finch wrote: > >Note that I'm not arguing against a new RR type, I'm just trying to >understand the arguments against the de facto standard. > >One significant advantage which I have not seen clearly articulated is >that a new RR type could combine the functions that

Re: Context specific semantics was Re: uncooperative DNSBLs, was several messages

At 5:06 AM -0800 11/14/08, John Levine wrote: > >The whole approach here is "An A record in this zone has a meaning >>different from the meaning in other zones". That creates a DNS >>context for the RRTYPE based on the zone of the query, which is not >>what the DNS currently uses for disambiguatin

Re: [BEHAVE] Can we have on NAT66 discussion?

Hallam-Baker, Phillip wrote: > BGP is not a secure protocol. > > We may work out a way to make BGP somewhat more secure, but most likely > to defend against attacks such as flooding and DDoS rather than > impersonation of end entities. > > So why do you think it is appropriate for end user appl

Re: uncooperative DNSBLs, IETF misinformation (was: several messages)

On Fri, Nov 14, 2008 at 3:19 AM, <[EMAIL PROTECTED]> wrote: >> - DNSBLs break email deliverability. >>(DNSBL technology in fact ensures that the email sender is notified >>if an email is rejected, unlike Bayesian filters/content filters >>which place spam in the user's trash without n

RE: [BEHAVE] Can we have on NAT66 discussion?

DL> Port/Overload NAT for IPv4 (NAT:P) has security benefits > in that it requires explicit configuration to allow for > inbound unsolicited transport connections (via port forwarding) > to 'inside' hosts. Perhaps you missed this statement from

adm plea: avoid/reduce massive cross-posting? (was: Can we have on NAT66 discussion?)

this thread has been posted to *4* mailing list. not sure whether other list adm had the same issue, but rrg adm keeps getting lots non-member posting warnings ... so the msg would not get delivered without manual intervention (i.e. defeating the intention of cross posting) wonder if there

RE: [BEHAVE] Can we have on NAT66 discussion?

BGP is not a secure protocol. We may work out a way to make BGP somewhat more secure, but most likely to defend against attacks such as flooding and DDoS rather than impersonation of end entities. So why do you think it is appropriate for end user applications to make assumptions about end e

Re: [BEHAVE] Can we have on NAT66 discussion?

Could people who are interested in discussing NAT66 please do so on the [EMAIL PROTECTED] mailing list and drop all of these cc:s? You may not be aware, but you are sending this mail to thousands of people, and most folks who care about NAT66 are getting this more than once. People who w

FTP to HISTORIC? RE: [BEHAVE] Can we have on NAT66 discussion?

The Internet has two protocols that account for >95% of user interactions, email and Web. Pointing out that one of those protocols involves an IP address change en-route might be a single data point but it is a significant one. Also note that the same is true of IRC, Jabber and other 'chat' typ

Re: Who Wants an RFID Badge for the Upcoming IETF Conference?

On Nov 14, 2008, at 7:36 AM, Andrew G. Malis wrote: I just added my name to the database. What I would REALLY like is to just have my badge scanned when I enter a meeting room instead of signing a blue sheet. That would have required Henning and/or Athar to coordinate with the Secretariat b

Re: Last Call: draft-ietf-sieve-refuse-reject (Sieve Email Filtering: Reject and Extended Reject Extensions) to Proposed Standard

My apologies for the extremely delayed reply to this review. I've at long last cleared enough time to get into the grist of the comments on this draft and prepare revision -08. On Aug 11, 2008, at 8:36 AM, Spencer Dawkins wrote: I have been selected as the General Area Review Team (Gen-ART

Re: [BEHAVE] Can we have on NAT66 discussion?

Hi Darrel, Comments below On Thu, Nov 13, 2008 at 9:30 PM, Darrel Lewis (darlewis) <[EMAIL PROTECTED] > wrote: > Comments below inline with DL> > NAT66 is in fact a security requirement in many applications and in others > it is a compliance requirement. Stampy feet protests that the idea is > pr

RE: [P2PSIP] P2PSIP diagnostics: PING discussion

Colin, In the p2psip diagnostics draft, we also say that we use the "NTP format" time. Best Regards, Song Haibin Email: [EMAIL PROTECTED] Skype: alexsonghw _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Colin Perkins Sent: Friday, November 14, 2008 3:34 AM To:

Re: uncooperative DNSBLs, was several messages

On Thu, Nov 13, 2008 at 06:15:53PM -0500, Keith Moore wrote: > For instance, what would happen if mail servers provided feedback to > both senders (on a per message basis in the form of NDNs) and recipients > (say, via a web page that listed messages blocked due to DNSBLs)...in > both cases describ

Re: [P2PSIP] P2PSIP diagnostics: PING discussion

Neither XP nor Mac OS X can be relied on to have accurate time sync, although they in theory come with time syncing enabled by default. Unfortunately, you just can't rely on synchronized clocks in all but the most controlled of circumstances (and I think it's almost always a poor idea, even then).

RE: [BEHAVE] Can we have on NAT66 discussion?

Eric, Philip, Comments below inline with DL> Thanks. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Klein Sent: Thursday, November 13, 2008 11:07 AM NAT66 is in fact a s

Re: [BEHAVE] Can we have on NAT66 discussion?

Hi Phillip, On Thu, Nov 13, 2008 at 5:06 PM, Hallam-Baker, Phillip <[EMAIL PROTECTED]>wrote: > I beleive that the question would not arise If we had a coherent Internet > architecture > > The idea that an application can or should care that the IP address of a > packet is constant from source to

Re: several messages

On Wed, Nov 12, 2008 at 11:33:46AM -0800, Randy Presuhn wrote: > Huh? Concrete, real example: I send a message to an IETF mailing list. > A list subscriber's ISP rejects the forwarded message. IETF's mailman > drops the subscriber, because this has been happened multiple times. > I can't notify

RE: Context specific semantics was Re: uncooperative DNSBLs, was several messages

On Fri, 14 Nov 2008, Hardie, Ted wrote: > > Since you now have two different meanings for what an A record is, you > now need two different code trees that understand what A records are, > and those code trees are not interoperable. What do you mean by "interoperable" here? What would it mean for

RE: Context specific semantics was Re: uncooperative DNSBLs, was several messages

From: Tony Finch [EMAIL PROTECTED] On Behalf Of Tony Finch [EMAIL PROTECTED] Sent: Friday, November 14, 2008 4:11 AM To: Hardie, Ted Cc: Andrew Sullivan; ietf@ietf.org Subject: Re: Context specific semantics was Re: uncooperative DNSBLs, was several messag

Re: Who Wants an RFID Badge for the Upcoming IETF Conference?

I just added my name to the database. What I would REALLY like is to just have my badge scanned when I enter a meeting room instead of signing a blue sheet. Cheers, Andy On Thu, Nov 13, 2008 at 10:39 PM, Athar Shiraz Siddiqui <[EMAIL PROTECTED]> wrote: > Dr. Henning has asked us to install a syst

Weekly posting summary for ietf@ietf.org

Total of 318 messages in the last 7 days. script run at: Fri Nov 14 00:53:02 EST 2008 Messages | Bytes| Who +--++--+ 9.43% | 30 | 8.01% | 174259 | [EMAIL PROTECTED] 4.09% | 13 | 8.53% | 185509 | [EMAIL PROTECTE

Re: Context specific semantics was Re: uncooperative DNSBLs, was several messages

>The whole approach here is "An A record in this zone has a meaning >different from the meaning in other zones". That creates a DNS >context for the RRTYPE based on the zone of the query, which is not >what the DNS currently uses for disambiguating the types of >requests/responses. Didn't that pl

Re: Context specific semantics was Re: uncooperative DNSBLs, was several messages

On Thu, 13 Nov 2008, Ted Hardie wrote: > > That's an example in which an A record in this zone has the standard DNS > meaning and the expectation is that you can use it construct a URI. > The other A records have a specific meaning in which the data returned > indicates that indicates something abo

RE: uncooperative DNSBLs, IETF misinformation (was: several messages)

> >> - DNSBLs are a temporary fad, they'll never last. > >>(we've been serving DNSBLs for 10 years) > > > > Longevity is no guarantee of future survival. > > A good argument against publishing a standard for any > technology at all. Not at all. But it seems to me that the IETF does try to de

Re: uncooperative DNSBLs, IETF misinformation (was: several messages)

On 14 Nov 2008, at 09:19, <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> wrote: - DNSBLs are a temporary fad, they'll never last. (we've been serving DNSBLs for 10 years) Longevity is no guarantee of future survival. A good argument against publishing a standard for any technology at all. -

Re: [BEHAVE] Can we have on NAT66 discussion?

On 13 nov 2008, at 23:50, Hallam-Baker, Phillip wrote: The most successful Internet protocols do not involve connections to hosts today. SMTP is a connection to a service and has been for two decades. In SMTP the IP address does not remain constant end to end and never did. SMTP is also

RE: uncooperative DNSBLs, IETF misinformation (was: several messages)

> - DNSBLs are temporary fad, they'll never last. >(we've been serving DNSBLs for 10 years) Longevity is no guarantee of future survival. > - DNSBLs are bad for email. >(we alone flag some 80 billion spam emails *per day*, spam which >would otherwise clog servers and render email comp