Am 04.02.2015 um 20:47 schrieb Robert Moskowitz:
I have been 'working' with my new ISP for a couple weeks to get the rDNS
setup for my server move (I am changing ISPs for a number of reasons). I
was assured on signing that setting up rDNS was 'easy'; it is not.
DIGing up the SOA on my IP rDNS tends to indicate that they have not
updated that zone for many months.
RDNS is a prerequisite *before* setupa MTA not the other direction
And that 50-253-254-9-static.hfc.comcastbusiness.net has no RR (e.g. A
or CNAME).
Is there someway to get postfix to provide the needed inforation to the
recipient MTA that this is OK and valid?
you and your postfix are not in the position to provide any infromation
i that context - the receiving MTA asks for the PTR of the connecting IP
I am asking, but I suspect that even if I send out things OK, there will
be MTAs out there that will not let their clients send mail to me as my
rDNS does not match.
it don't matter if it matches - if you are coming with such a PTR you
are rejected - on my setup this is skipped at least if the envelope
domain has a SPF policy listing that IP or if you are on one of 11
public DNSWL
ptr-check.sh 50-253-254-9-static.hfc.comcastbusiness.net
REJECT Generic DNS-Reverse-Lookup (PTR-Rule: 417) see
http://www.emailtalk.org/ptr.aspx or configure
http://en.wikipedia.org/wiki/Sender_Policy_Framework
I am pushing the ISP that will remain unnamed. (oops. :) ) I was
told that 'they are working on it'. Meanwhile I am paying double as I
cannot migrate my server.
'they are working on it'?
they are idiots - it takes 5 seconds to change the Reverse DNS for the
IP to "mail.htt-consult.com" on their nameservers and the A-record is
completly in your hands
well, because i got tired about how long ISP's need for simple changes
and then more than once *add* the requested PTR instead replace it and
so email becomes a lottery i had a fight to get the reverse zone for our
/24 delegated to my own nameservers and so now control each record as
well as the TTL
