Alex van den Bogaerdt wrote:
- The resulting addresses MUST have PTR records, and these PTR records
MUST match the host. The following lookups will still work but are
discouraged:
somehost -> a.b.c.d; a.b.c.d -> otherhost; otherhost -> a.b.c.d
The following will NOT result in a valid lookup:
somehost -> a.b.c.d; a.b.c.d -> otherhost; otherhost -> p.q.r.s
I am starting to feel that FCrDNS (forward-confirmed reverse dns) is a Good
Thing for checking "who is responsible for this IP" and that blocking hosts
with missing or bad reverse DNS is a Good Thing too.
I don't know if I would require the extensive checking of the MX records as
Alex suggests here. I think it's much more valuable to check the IP of the
server connecting to me with FCrDNS than to fully check out the MX records
for the RHS. It's not a bad thing, but it just seems like extra work to me.
However, I DO support any effort that blocks RHS domains that have no MX.
Fallback to A is not yet fully deprecated (viz. all the messages I have
received from Declude systems claiming to be from
postmaster(_at_)boxname(_dot_)whatever(_dot_)com that I can't reply to at all).
In the future, when all mailservers are configured the Right Way, we can
get away with blocking:
RHS with no MX
RHS with MX of 10.0.0.1 or other rfc1918
RHS with MX 0 . since "." has no A records, some folks use this as an
early form of "v=spf1 -all"
IP connections from host with no PTR
IP connections from host with bogus PTR that doesn't resolve forward
(like some broken cable modems)
IP connections from host with forged PTR that resolves, but not back to
the same IP (such as spammers who stuff their PTR records with
"microsoft.com" or such)
IP connections from host with "host unreachable" or "timeout" when
looking up PTR (give them a 4xx temporary code that says "try again when
your DNS server is up")
--Philip Gladstone <philip-spf(_at_)gladstonefamily(_dot_)net> wrote:
This implies that I cannot run a mail server on a cable modem. This is
uncool. The reason is that the a.b.c.d -> otherhost which typically
doesn't map to anything.
You have to allow for the case where the a.b.c.d is administratively
controlled by someone other than the system administrator.
It looks like from your other reply that your ISP fixed it so forward
lookups now work. I would recommend strongly that folks with "PTR records
not quite done right" should complain to their ISP. If you get back some
otherhost that doesn't map to anything, and that is deemed OK, spammers
will forge on. If you get back some otherhost that maps to someone (like
microsoft.com) but not back to your IP, spammers will forge on.
But, dynamic adsl/cable ISPs have a bigger problem on their hands, namely
all the virus and hijacked-box-spam... I predict that more and more ISPs
will just start blocking connections from their space to remote machines'
port 25. Then you will be forced to push out through their smart host.
The "ideal" case would be to severely rate-limit outbound connections to
remote port 25, so that a dialup user configured wrong can get a few
messages out, but sending 100 or more would block their IP. Most ISP's
don't have the $$ to arrange this though. Also, it's not that hard for an
ISP to block outbound-to-port-25 and then allow unblocking on request, if
you are running your own mail server and promise to behave.
--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>