On Wed, 14 Feb 2007 22:52:45 -0500 (EST) Dean wrote: DA> As an exercise, try to show DA> that Administrator A, acting as Story described, has acted unreasonably DA> (as Lemon asserted) when Administrator A can quote the text of this DA> draft in his defense.
Let's do two exercises. Given a document with the wording your propose, try and convince Administrator A that he MUST NOT use a system that he's already determined to effective. I think saying apps SHOULD NOT depend on reverse mapping is ok; the rfc 2119 definition still allows administrators to decide to use it in their environment, however unreasonable that seems to others. DA> I do feel the wording is way too weak. Basically, everyone should DA> consider that if this document is approved as is, and Administrator A DA> blocks your email because, e.g., it has the word "dialup" in the reverse DA> mapping entry, then Administrator A will refer to this document as proof DA> of the reasonableness of his actions. They don't need this document for that. All they need is their own statistics on the percentage of dialup or dynamic host spewing SPAM. You keep going on about how reverse DNS isn't proof of security and pointing your finger at me. But the example I gave is not using it to provide security - it is using it as proof of insecurity. DA> Likewise, if the reverse mapping doesn't exist, DA> or doesn't "match" the forward mapping, etc, they will DA> also point to this document as justification for their behavior. Forward Confirmed reverse DNS is an entirely different beast. I would be in favor of the document have strong wording against this type of check, because there are very good reasons why an ip address might be associated with multiple domains. Anyone who tries using this method would quickly for email would quickly find out it's a bad idea (see http://news.com.com/2100-1023-982118.html). -- Robert Story SPARTA
signature.asc
Description: PGP signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
