On Fri, Jan 27, 2006 at 05:32:57PM -0500, Andrew Sullivan <[EMAIL PROTECTED]> wrote a message of 54 lines which said:
> The discussion in section 3 notes that there are a number of > unfortunate consequences of missing IN-ADDR. It seems to me > therefore that the recommendations in section 4 come out as a little > too ambivalent: the suggestion appears to be that IN-ADDR is a good > thing, but that people shouldn't really use it. If I may, IMHO, the real issue is not wether PTR are good or not but "Are people able to create and modify them?" and the answer is NO for many cases. Because, even if you love PTR and you want to add them, you depend on persons above (in the DNS reverse tree) you. I deeply regret that the draft does not emphasize this problem (may be because IETFers are typically working near the ".arpa" apex and do not see the problems of the poor guys at the bottom of the tree). Therefore, mandating the use of PTR records is a Bad Thing. [I can add that getting a ip6.arpa or in-addr.arpa delegation from above is more difficult in some parts of the world. Mandating PTR records means banning Africa, for instance.] > The reason I think this is that there are some cases where IN-ADDR, > particularly coupled with the lookup from the PTR, is still a good > basis on which to take a decision. Email remains, I suspect, the > best example, because of the hordes of spambot nets. I've often read that and I always challenge the persons who claim so to back these claims with surveys, figures, etc. With most IAP, every PC gets a PTR, wether it hosts a zombie or not, so I doubt it can be a spam indicator. > But some pointers to those other methods would probably be needed if > one is going to convince people not to continue to rely on this > method. I disagree: when an idea is a bad one, you can say so even if you have nothing to replace it right now. Many sysadmins would like to have a sure way to tell if a SMTP client is a spammer or not and they are ready to rely on snake oil for that. IMHO, the IETF should tell them that there is no magic solution. . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
