CentOS - Feb 2012 - postfix - reject of incoming mail due to helo check??

Hi list,
I have been getting the following types of log messages

Jan 30 08:22:33 ndgonline postfix/smtpd[30538]: NOQUEUE: reject: RCPT 
from unknown[71.46.229.50]: 450 4.7.1 Client host rejected: cannot find 
your hostname, [71.46.229.50]; from=<DWoodman at orangebankfl.com> 
to=<rkampen at ndgonline.net> proto=ESMTP
helo=<mail.floridianbank.com>

a rdns check shows all is well with 71.46.229.50 - it belongs to the 
from senders domain name.

;; ANSWER SECTION:
50.229.46.71.in-addr.arpa. 777    IN    PTR    mail2.orangebankfl.com.

It seems it is being rejected due to the helo domain name - which does 
not have a correct rdns.

My problem is that I do not specify the helo check??

this is the relevant portion of main.cf

<snip>
smtpd_helo_required = yes
smtpd_delay_reject = yes
#added 20090410
strict_rfc821_envelopes = yes
smtpd_helo_restrictions     permit_mynetworks,
    reject_non_fqdn_helo_hostname,
    reject_invalid_helo_hostname,
    permit

smtpd_sender_restrictions    permit_mynetworks,
   permit_sasl_authenticated,
   reject_non_fqdn_sender,
   reject_unknown_client,
   reject_unauthenticated_sender_login_mismatch,
   permit

smtpd_sender_login_maps = hash:/etc/postfix/smtpd_sender_login_map

smtpd_client_restrictions    check_client_access hash:/etc/postfix/access

smtpd_recipient_restrictions    reject_unauth_pipelining,
   reject_non_fqdn_recipient,
   reject_unknown_sender_domain,
   reject_unknown_recipient_domain,
   permit_mynetworks,
   permit_sasl_authenticated,
   reject_unauth_destination,
   check_sender_access hash:/etc/postfix/sender_access,
   check_recipient_access hash:/etc/postfix/roleaccount_exceptions,
   check_helo_access pcre:/etc/postfix/helo_checks,
    reject_rbl_client sbl-xbl.spamhaus.org,
    reject_rbl_client cbl.abuseat.org,
    reject_rbl_client dul.dnsbl.sorbs.net,
   check_policy_service unix:postgrey/socket,
   permit

#  reject_unauthenticated_sender_login_mismatch

smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
#, noplaintext
broken_sasl_auth_clients = yes

</snip>

so no reject_unknown_helo_hostname check - so why is it throwing them out?

Thanks for anyone's insight.

On 02/02/2012 11:01 AM, Rob Kampen wrote:
> Hi list,
> I have been getting the following types of log messages
>
> Jan 30 08:22:33 ndgonline postfix/smtpd[30538]: NOQUEUE: reject: RCPT
> from unknown[71.46.229.50]: 450 4.7.1 Client host rejected: cannot find
> your hostname, [71.46.229.50]; from=<DWoodman at orangebankfl.com>
> to=<rkampen at ndgonline.net>  proto=ESMTP
helo=<mail.floridianbank.com>
>
> a rdns check shows all is well with 71.46.229.50 - it belongs to the
> from senders domain name.
>
> ;; ANSWER SECTION:
> 50.229.46.71.in-addr.arpa. 777    IN    PTR    mail2.orangebankfl.com.
>
> It seems it is being rejected due to the helo domain name - which does
> not have a correct rdns.
>
> My problem is that I do not specify the helo check??
>
> this is the relevant portion of main.cf
>
> <snip>
> smtpd_helo_required = yes
> smtpd_delay_reject = yes
> #added 20090410
> strict_rfc821_envelopes = yes
> smtpd_helo_restrictions >      permit_mynetworks,
>      reject_non_fqdn_helo_hostname,
>      reject_invalid_helo_hostname,
>      permit
>
> smtpd_sender_restrictions >     permit_mynetworks,
>     permit_sasl_authenticated,
>     reject_non_fqdn_sender,
>     reject_unknown_client,
>     reject_unauthenticated_sender_login_mismatch,
>     permit
>
> smtpd_sender_login_maps = hash:/etc/postfix/smtpd_sender_login_map
>
> smtpd_client_restrictions >     check_client_access
hash:/etc/postfix/access
>
> smtpd_recipient_restrictions >     reject_unauth_pipelining,
>     reject_non_fqdn_recipient,
>     reject_unknown_sender_domain,
>     reject_unknown_recipient_domain,
>     permit_mynetworks,
>     permit_sasl_authenticated,
>     reject_unauth_destination,
>     check_sender_access hash:/etc/postfix/sender_access,
>     check_recipient_access hash:/etc/postfix/roleaccount_exceptions,
>     check_helo_access pcre:/etc/postfix/helo_checks,
>      reject_rbl_client sbl-xbl.spamhaus.org,
>      reject_rbl_client cbl.abuseat.org,
>      reject_rbl_client dul.dnsbl.sorbs.net,
>     check_policy_service unix:postgrey/socket,
>     permit
>
> #  reject_unauthenticated_sender_login_mismatch
>
> smtpd_sasl_auth_enable = yes
> smtpd_sasl_security_options = noanonymous
> #, noplaintext
> broken_sasl_auth_clients = yes
>
> </snip>
>
> so no reject_unknown_helo_hostname check - so why is it throwing them out?
>
mail.floridianbank.com != mail2.floridianbank.com

culprit => reject_non_fqdn_helo_hostname

but I would not disable it.


-- 

Ljubomir Ljubojevic
(Love is in the Air)
PL Computers
Serbia, Europe

Google is the Mother, Google is the Father, and traceroute is your
trusty Spiderman...
StarOS, Mikrotik and CentOS/RHEL/Linux consultant

On Thu, Feb 02, 2012 at 11:01:52PM +1300, Rob Kampen
wrote:
> 50.229.46.71.in-addr.arpa. 777    IN    PTR    mail2.orangebankfl.com.
However:
% getent hosts mail2.orangebankfl.com.
71.43.202.234   mail2.orangebankfl.com

71.46.229.50  != 71.43.202.234

Senders DNS is broken.  rDNS lookup validation is failing.

-- 

rgds
Stephen

On 02/02/12 10:01, Rob Kampen wrote:
> Hi list,
> I have been getting the following types of log messages
>
> Jan 30 08:22:33 ndgonline postfix/smtpd[30538]: NOQUEUE: reject: RCPT
> from unknown[71.46.229.50]: 450 4.7.1 Client host rejected: cannot find
> your hostname, [71.46.229.50]; from=<DWoodman at orangebankfl.com>
> to=<rkampen at ndgonline.net>  proto=ESMTP
helo=<mail.floridianbank.com>
>
> a rdns check shows all is well with 71.46.229.50 - it belongs to the
> from senders domain name.
>
> ;; ANSWER SECTION:
> 50.229.46.71.in-addr.arpa. 777    IN    PTR    mail2.orangebankfl.com.
>
> It seems it is being rejected due to the helo domain name - which does
> not have a correct rdns.
>
No, the error is:

Client host rejected: cannot find your hostname, [71.46.229.50]

<snip>
>
> smtpd_sender_restrictions >     permit_mynetworks,
>     permit_sasl_authenticated,
>     reject_non_fqdn_sender,
>     reject_unknown_client,
>     reject_unauthenticated_sender_login_mismatch,
>     permit
>
and you have reject_unknown_client above.

Postfix is attempting a rDNS lookup against the client IP 
[71.46.229.50], it temp failed for whatever reason (not that uncommon) 
so the client is "unknown" and you rejected it accordingly.

See the Postfix documentation entry for more info:

reject_unknown_client_hostname (with Postfix < 2.3: reject_unknown_client)
     Reject the request when 1) the client IP address->name mapping 
fails, 2) the name->address mapping fails, or 3) the name->address 
mapping does not match the client IP address.
     This is a stronger restriction than the 
reject_unknown_reverse_client_hostname feature, which triggers only 
under condition 1) above.
     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 or name->address lookup failed due to a temporary 
problem.


I would recommend removing reject_unknown_client from your 
smtpd_sender_restrictions.

Hope that helps.

On Fri, Feb 3, 2012 at 8:14 AM, Reindl Harald <h.reindl at thelounge.net>
wrote:
>
> on both sides of the NAt you need a DNS with the correct mapping
> the host on the other side is not interested in your NAT
> it sees a IP, a HELO and DNS-Records
>
> so it is YOUR job as admin to provide the correct HELO for your
> outgoing IP and even configure the DNS behind the NAT correctly
> if you like it really clean
Your HELO has nothing to do with your source IP, and you can't
possibly expect a multi-homed server to adjust its HELO to the
interface it happens across.   Expecting the reverse DNS of the source
IP to give a name that has the same IP in an A record lookup is
somewhat different, but still I don't think that is an actual
requirement.   As a mail admin, you are of course free to discard your
users' mail for any whimsical reason you like, but if you want to say
it is a requirement, please quote the MUST in an RFC.

-- 
   Les Mikesell
    lesmikesell at gmail.com

On Fri, Feb 3, 2012 at 10:28 AM, Reindl Harald <h.reindl at thelounge.net>
wrote:
>
> it is quite easy to know the mail-flow and from what public
> interface mails are going out and hwatever that ip is get
> a A-Record and matching PTR and that is what "myhostname"
> has to be set to
RFC quote, please.

-- 
   Les Mikesell
     lesmikesell at gmail.com

On Fri, Feb 3, 2012 at 12:51 PM, Reindl Harald <h.reindl at thelounge.net>
wrote:
>
>>> a A-Record and matching PTR and that is what "myhostname"
>>> has to be set to
>>
>> RFC quote, please
>
> you need A RFC to know with what IP your machines connecting outside?
> who should know and write it for you?
> maybe you have the wrong job or talking about things are not yours?
>
> also nobody needs RFCs for bad practices
> as said: ignore them, but do not whineif your server is ognored?
I understand you have your own opinion on the matter.  I am requesting
facts. If someone wants to whimsically discard my mail, they are free
to do so.

-- 
   Les Mikesell
    lesmikesell at gmail.com

On Fri, Feb 03, 2012 at 08:04:31PM +0100, Reindl Harald
wrote:
> Am 03.02.2012 20:01, schrieb Stephen Harris:
> > In this, Les is correct.  The RFCs merely say the HELO needs to _a_
valid
> > identifier for the host.  Indeed this discussion was on this list back
in
> > July ("SPAM on the List") where I pointed out that RFC 5321
says
> 
> i know the RFCs
> 
> does not change that it is a dmaned good idea this days
> to make matching A/PTR/HELO and it is EASY to do this
A & PTR, yes.  HELO, no.  It's not even possible to do HELO matching PTR
when NAT gets in the way.

-- 

rgds
Stephen

On Fri, Feb 03, 2012 at 10:34:20PM +0100, Reindl Harald
wrote:
> 
> 
> Am 03.02.2012 20:58, schrieb Stephen Harris:
> > On Fri, Feb 03, 2012 at 08:04:31PM +0100, Reindl Harald wrote:
> >> does not change that it is a dmaned good idea this days
> >> to make matching A/PTR/HELO and it is EASY to do this
> > 
> > A & PTR, yes.  HELO, no.  It's not even possible to do HELO
matching PTR
> > when NAT gets in the way.
> 
> WHAT has NAT to do with this?
> 
> my mailserver has intern 10.0.0.x, external 91.118.73.x
> my internal DNS has the PTR/A for the NAt address
> external DNS have the PTR/A for the public idea
> 
> what in the world let you think that NAT does change anything?
If your mail server talks to machine with IP address 1.2.3.4 then should
it say HELO with the 10 address name or the 91 address name?

The mail server doesn't know what IP address will be presented to the
remote machine, so it can't pick the correct name for the HELO.

This is why I agree that A/PTR values should match, but there's no
way for the HELO value to match.

-- 

rgds
Stephen

On Fri, Feb 03, 2012 at 11:17:29PM +0100, Reindl Harald
wrote:
> Am 03.02.2012 22:58, schrieb Stephen Harris:
> > If your mail server talks to machine with IP address 1.2.3.4 then
should
> > it say HELO with the 10 address name or the 91 address name?
> 
> if you are not too stupid your internl view and external view of
> dns-names is identical and there is no difference
*boggle* What?  Wow.  No.  Just no.  That won't even work on a
toy home network where your ISP sets the rDNS, it definitely won't
work on a large corporate network.  It only works in a trivial
environment.

If you're telling me that my internal mail servers must talk to each
other via the name pool-173-71-187-61.pitbpa.fios.verizon.net then...
well, never mind.

-- 

rgds
Stephen

On Fri, Feb 03, 2012 at 11:47:06PM +0100, Reindl Harald
wrote:
> Am 03.02.2012 23:32, schrieb Stephen Harris:
> > If you're telling me that my internal mail servers must talk to
each
> > other via the name pool-173-71-187-61.pitbpa.fios.verizon.net then...
> > well, never mind.
> 
> i am telling you that your network design is poor and yes if THIS is
> your rDNS it has to be your HELO
Fortunately, you're wrong.  The real world doesn't work the way you
think it should.  Which is a relief to everyone else!

-- 

rgds
Stephen