Thank you for the response Todd.
On Tue, 2012-04-03 at 07:36 -0700, Todd Lyons wrote:
> On Tue, Apr 3, 2012 at 6:52 AM, Ron White <exim.ml@???> wrote:
> > I've been working with a client running Exim on a cheap shared host who
> > has been having some odd delivery issues. Normally I don't get too
> > involved in these, but it was interesting. It only affects some
> > recipients some of the time and the only reason I can find for the
> > inconstancy is what appears to be a bit of a hooky DNS set up.
>
> Simple test: set your system resolver to use 8.8.8.8 and 8.8.4.4
> instead of whatever DNS resolver it's using now.
dig @8.8.8.8 +short whub28.webhostinghub.com.
205.134.241.17
205.134.224.208
dig @8.8.8.8 +short whub28.webhostinghub.com.
205.134.224.208
205.134.241.17
>
> > The host concerned has a PTR record, it's a bit of a mess, but it's
> > there:
> > dig -x 205.134.224.208
> >
> > 208.224.134.205.in-addr.arpa. 17019 IN CNAME
> > 208.128-255.224.134.205.in-addr.arpa.
> > 208.128-255.224.134.205.in-addr.arpa. 65020 IN PTR
> > whub28.webhostinghub.com.
>
> SOP for doing rDNS for non 8 bit boundaries.
I'm sorry Todd, I don't understand that?
>
> > However, digging this gives two A records/IP's back rotating on a round
> > robin:
> >
> > dig +short whub28.webhostinghub.com.
> > 205.134.241.17
> > 205.134.224.208
> > dig +short whub28.webhostinghub.com.
> > 205.134.224.208
> > 205.134.241.17
> > dig +short whub28.webhostinghub.com.
> > 205.134.241.17
> > 205.134.224.208
> >
> > I think this may be a problem with PTR resolution because if the reverse
> > lookup for a connecting IP gives the name whub28.webhostinghub.com, but
> > the matching double check on that back to an IP gives two records back
> > will the average mail resolver see both of these and satisfy the check,
> > or will it take the top one only and spot the mismatch between the
> > original connecting IP and the RrDNS?
>
> No sites should require the forward DNS and the rDNS to be the same.
> It's perfectly logical to expect rDNS to resolve to something,
> anything, but not to make it match forward DNS.
You don't think so?
I used to see anti-spam settings that penalised on this. In fact I think
Postfix can be set to do this:
reject_unknown_reverse_client_hostname
Reject the request when the client IP address has no
address->name mapping.
This is a weaker restriction than the
reject_unknown_client_hostname feature, which requires not only
that the address->name and name->address mappings exist, but
also that the two mappings reproduce the client IP address.
The unknown_client_reject_code parameter specifies the response
code for rejected requests (default: 450). The reply is always
450 in case the address->name lookup failed due to a temporary
problem.
This feature is available in Postfix 2.3 and later.
>
> I still suspect it's your DNS.
It's not my system where this is happening. It is a small number of
remote receiving hosts that defer or reject mail based on this.
Typically running Postfix, Barracuda or sometimes even Postini.
>
> Have you verified that you have clean MTU path all the way to the
> hosts which are giving you problems? Is there an overzealous firewall
> that blocks all ICMP (breaking path mtu discovery)?
See above.
>
> ...Todd
> --
> Always code as if the guy who ends up maintaining your code will be a
> violent psychopath who knows where you live. -- Martin Golding
>
