Jesse Stroik wrote:
In my experience, I've come across exchange servers in private networks
behind mail gateways that were the originating server. In this case,
whether or not you and I think it is a poor configuration, it is a
legitimate SMTP configuration via the RFC and it will have no
reverse-DNS entry for the originating server.
^^^^^^^^^^^^^^^^^^^^^^^^^^
Quite possible, but the original argument, as I'll point out again, is
for rejecting mail with **NO** rDNS *at all*. This *is* a different
case than malformed or mismatched rDNS information.
Eg, "host <sending IP according to you mail server>" returns NXDOMAIN.
Try it with 209.91.179.65 - if the device on that IP were a NAT/firewall
(it isn't) with a device generating legitimate SMTP traffic behind it
somewhere, that IP should have rDNS (it doesn't right now - should
probably fix that anyway).
To be excessively pedantic even network and broadcast IPs should have
rDNS - IMO there's little excuse not to have *some* kind of rDNS on
every single IP delegated from ARIN, RIPE &c. ("We just got assigned a
new /20 and we haven't set them up yet" is one such valid excuse. <g>)
If it's contacting your mail server, it's either a local private
network, your ISP's network is sufficiently mismanaged as to allow
private-IP network traffic to reach public IP space, or there is a
publicly-routeable IP associated with that connection. I can't think of
any cases in which that public IP should NOT have *something* in rDNS -
whether it's valid, well-formed, properly closed-loop, or related in any
way to the SMTP traffic is another question.
(As an ISP mail administrator I see a lot of "ooh, that looks neat..
but..." ideas go across this list; most of them have enough potential
to cause customer phone calls that I don't look very far into the
details of implementing them. *sigh* My own personal machine receives
so little traffic I don't mind the cost of running SA - and in fact I
run it largely the way I do the systems at work to keep things simple.)
-kgd
