Re: [exim] Subtle delivery issue - BROKEN DNS PTR questions.

Pàgina inicial
Delete this message
Reply to this message
Autor: exim.ml@riotm.co.uk
Data:  
A: exim-users
Assumpte: Re: [exim] Subtle delivery issue - BROKEN DNS PTR questions.
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
>