On Wed, 14 Feb 2007, Edward Lewis wrote:

> At 19:50 -0500 2/14/07, Dean Anderson wrote:
> 
> >I am not declaring a consensus. I am stating, based on the history of
> >discussion the various drafts, that most people agree with my views on
> >this topic in contrast to, for example, Mr. Story's views.  If anything,
> >I am asking for a consensus call on the 3 statements I proposed.

[...]

> I am asking, based on what evidence are you asserting "most people",
> therefore "consensus"  has been achieved?

I've said History. You have access to the archives. Here are some:

Re: comment on draft-ietf-dnsop-inaddr-required-02.txt
by Kevin Darcy <[EMAIL PROTECTED]>, Tue, 07 Aug 2001 
"But, why use reverse DNS at all? It leads to all sorts of bad security
practices, half-solutions to real problems (like the spam problem) and a
*false* sense of security."


At 10:01 PM 9/12/01, Kevin Darcy wrote:
>I oppose adoption/advancement of the draft. Not only are the security
>justifications null and void, I think they actually *detract* from the
>other justifications inasmuch as they promote/encourage bad security
>practices and/or risk creating a False Sense of Security.



Re: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt
by JINMEI Tatuya  Fri, 04 Apr 2003
"Secondly, if I don't misunderstand the intention, the draft says two
things:
[...]
"2. applications should not rely on reverse mapping for several
   purposes as they currently do.  The discouraged purposes include:
   - rejecting ftp/telnet connections just due to the lack of reverse
     mapping or failure of reverse-forward-reverse match.
   - filtering rule in TCP wrappers due to the lack of reverse mapping
   - regarding e-mail messages as spam if the sender address does not
     have a reverse mapping"

[JINMEI did misunderstand the draft's intention. It did not DIScourage
these things, it ENcouraged them. JINMEI agrees, as I do, that they
should be DIScouraged.]


Re: [dnsop] Tangible harm caused by in-addr-required draft
by Ted Lemon Fri, 1 Apr 2005 
"> Dean Anderson writes:
> Basically, this says its ok to use in-addr based security, and if they
> don't match, that's a "security concern".
>
> In other words, matching in-addr is required.

"This is a legitimate, specific criticism.   One that I haven't seen  
from you before on the mailing list.   I very much support fixing  
cases where the text can be misread in the way you suggest.   It  
would be disastrous if someone read the document the way you suggest,  
and I can see where someone could make that mistake, although it  
wasn't obvious to me until you pointed it out. [...]"

[Oddly, I had been saying that all along, but apparently Ted didn't see
it.]

There's more, but I've made the point.

Basically, many people have greatly misunderstood this document, and
when those misunderstandings are eventually illuminated for them, they
agree with me.  That is, except for those people who vehemently agree
with Robert Story's viewpoint, such as Mans Nielson and some others. The
proponents have gone from calling for 'in-addr required' in 2000
(document name and title), to assuring us they didn't mean that in-addr
was required despite the document name (but it really was required, they
just put it in the ambigous text), to where we are now (changing the
document name). I assert that these misunderstandings indicate ambiguity
in the text, and that the text must be very carefully examined to avoid
the 'disastrous results' (quoting Ted Lemon)  that would result from the
mistake.

The present authors have not eliminated the previous ambiguity, but have
merely changed the wording to different, but still ambiguous, statements
with the same disastrous effect as before---still supporting the notion
that in-addr is required for security, that it is reasonable to block
email based on 'dialup' in the name, or because there is no in-addr RR,
etc (see section 4 of the current draft).

This document has not achieved consensus for many years (7 years?)  
because no one agrees with (eg) Robert Story's views, and once it become
clear the document endorses that view, it is sent back for revision.  
Perhaps you've forgotton some things:

Re: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt
by Ed Lewis Fri, 4 Apr 2003
"I'd recommend only working on the document if the tone is of a report 
on the current state of affairs and not that of a mission statement 
to fix the ills of a broken reverse map.  The former is useful and 
closure can be reached, the latter a rat hole without bottom."

Seems Section 4 of the current draft are just such 'ills of a broken
reverse map'. Of course, its not really "broken", it just doesn't
conform to the 1:1 scheme that the anti-spammers want everyone to use
and want the DNSOP WG to approve and encourage.

I hope I've jogged your memory, and cleared up a few things.

                --Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000   



_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www1.ietf.org/mailman/listinfo/dnsop

Reply via email to