Re: Review of draft-ietf-dnsop-inaddr-required

On Mon, Jan 30, 2006 at 09:41:13AM +0100, Stephane Bortzmeyer wrote:
> 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. 

I haven't run into this issue; but to the extent it's a problem (and
I've no reason to doubt you), you're quite right that the draft needs
to discuss it.

> > 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.

You're quite right that every PC usually gets a PTR; but the
technique that people use is to look at the greeting, look at the
results of the reverse lookup, and compare them.  If they don't match
(for some value of match -- often this means the greeting just needs
to be in the domain of the reverse lookup), you reject the
connection.

But in any case, you can't back this up with figures, &c., because
the decision is a subjective one.  It's a matter of how much you
trust the sender.  Since the problem of spam is basically one that
arises because of the low cost to the sender, then an email
administrator might legitimately decide that s/he is willing to make
it slightly harder to send mail to a site, in an effort to reduce the
junk that comes in.  The idea here is that of a bozo filter: if the
mail is coming from a site that hasn't managed to configure things so
that everything matches, then maybe you don't want mail from that
site.  Probably that mail should be coming through the ISP's mail
relay anyway, so this is a useful technique.

> > 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.

Sure.  But if one actually hopes to influence behaviour, one had
better have something to say about the goals of the behaving parties. 
If we believe the technique causes more harm than benefit, we need to
say why that is the case; and the "why" had better not be "some mail
won't get through", since that's the whole point.  I don't see that
in the draft at hand.  

If the idea is that the document should provide guidance to people
not to use the technique even though they believe it helps them,
then the argument needs to be stronger as to why it's a harmful
technique.  The document currently just says this:

   The use of IN-ADDR, sometimes in conjunction with a lookup of the
   name resulting from the PTR record provides no real security, can
   lead to erroneous results and generally just increases load on DNS
   servers.  Further, in cases where address block holders fail to
   properly configure IN-ADDR, users of those blocks are penalized.

If I were a current user of this technique, I'd respond this way:

1.	I don't want real security; I'm using this as a bit of
evidence in a probabilistic calculation.

2.	I don't mind the erroneous results, as I'd rather reject in
error than allow traffic I don't want.

3.	That's what the DNS is for.  I pay my ISP for this.

4.	I _want_ to penalise people who fail to properly configure
IN-ADDR.  I don't want such people communicating with me.

I know a lot of sysadmins who would respond exactly this way.  In
some cases, I have a great deal of sympathy for them.  Telling such
people, "Don't do this, and no we don't have an alternative," is a
way to ensure our advice is ignored.  

I'll note, by the way, that some people might be susceptible to the
argument that this isn't what the DNS is for, and that the ISP isn't
providing the service anyway, so that using this technique is as
costly to the rest of the Internet as spam is to the recipient (i.e.
that using this technique all the time causes the same free rider
problem spam itself causes).  So strengthening this part of the
document might help.

> 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

I don't think that's a fair characterisation of what the sysadmins
are doing.  They want a way to tell, on balance, whether their trust
limits are met for inbound connections.  It's a probabilistic, not a
binary, matter.  In some cases, they can afford to reject possibly
good traffic in favour of reduced traffic.  Making such decisions is
their job; that's why they're called "admins".

A

--

-- 
----
Andrew Sullivan                         204-4141 Yonge Street
Afilias Canada                        Toronto, Ontario Canada
<andrew <at> ca.afilias.info>                              M2P 2A8
                                        +1 416 646 3304 x4110

.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html