What does help is the record in reverse DNS (as in MTAMARK)
This ignores the reality of large ISPs, and all three network
registries, of
being lazy in delegating and enforcing correct reverse DNS to
begin with.
Ditto, re: RFC 2317.
I agree with Gordon here. I think that the reverse DNS is far
too flaky to rely on for more than hints. If ISPs want to
prevent non-mail servers from sending outbound mail they block
port 25. As a result of aggressive tactics by the blacklist
community this has become normal.
If what is being attempted is something less than blocking
port 25 completely then reverse DNS data makes good
sense. But we have to throw away the 'block incomming messages
from this address' semantics.
I think that the semantics people really want here are 'block
incomming messages unless additional authentication provided'.
I think that geting that defined would be very tricky.
This is why I suggest using a descriptive approach. Just tell
the receiver 'as the controller of the reverse DNS, IP Address
X is thought to be assigned to a dialup modem pool' or whatever
the address happens to be configured as. Let the recipient
allocate whatever score to that data that makes sense.
This approach has a bonus, it provides a lot of help if you are
trying to track a hacker. You have an indication of the type
of address the attack is comming from. That indication may
well be wrong, but that is always the case with takedown work.
If I knew which attacks came from dialup modems, those would be
the ones I would want to investigate in detail and build a case
to hand over to law enforcement.
As for accomodating client implementations, that's an
implementation problem
solved long ago with AUTH and SUBMIT and many other non-SMTP
mail injection
protocols. There are political and corporate reasons, not
technical, for
their lack of use.[1]
If we want to influence ISP behavior the best way to do that
is to write a BCP document in bullet point form that tells
them what to do. Then circulate it to ASTA and the like.