Little more on topic now:
There is common misconception that hijaking ip block implies being able
to do reverse dns for it. This is entirely false, one is ip routing issue
another is ip allocation deligated by RIR so to be able to do reverse dns
you would need to have record change with RIR (ARIN, APNIC, RIPE, LACNIC)
and they would know who the real ip owner is and would report hijacking.
But it is true that in some situations with smaller networks, they have
their reverse dns servers in the same ip as their block from the RIR, then
you could potentially setup your servers on the same ip. But lately that
is enough either as RIRs have changed to do in-addr deligation by domain
name and not ip, so you need to also hijack domain of the provider who you
are hijacking ip block from. As you can see it gets way too complex for a
spammer and can put him in way too much legal trouble if he's traced.
But I entirely agree that reverse dns check is no substitute for
authentication or verification. If you look at it carefully you'll find
that it fails on my complex mail path example both on the roaming user
part and on intermediate remailer. But checking reverse ip can be used for
the actual verification of individual server-server communication, I'll
mention difference in next email.
The only "authentication" strategy I think is bogus is using the reverse
DNS. This will at best demonstrate that the address block the IP is in has
been legitimately allocated. This is actually a modest spam indicator, it is
certainly not foolproof and is certainly not an accept/deny criteria. Lots
of legitimate IP addresses do not have reverse DNS configured. There are
definitely instances where garbage creators (high volume spam senders) have
hijacked unallocated IP ranges and advertised routes for them.
The problem is that it is almost as easy for the garbage creator to hijack a
legit IP address range by advertising a false route. So all things being
equal I would rather not create incentives for garbage creators to move to
strategies that are far more destructive.
Phill
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg