Score:1

Postfix white listing a badly configured server not working: Helo command rejected: Host not found;

ke flag

My mail server configuration is rather strict and some times incoming mails from legit servers get rejected because the remote end has a configuration problem, a common one is the HELO hostname.

I have a specific example that is from the most important electrical company in Italy, ENEL, that apparently sends transactional emails with an HELO hostname that does not resolve:

Feb 20 18:31:10 MYHOST postfix/smtpd[1748649]: NOQUEUE: reject: RCPT from mxrelay6.enel.com[146.133.127.102]: 450 4.7.1 <smtprelay.enel.com>: Helo command rejected: Host not found; from=<[email protected]> to=<MY CLIENT EMAIL> proto=ESMTP helo=<smtprelay.enel.com>

I am trying to whitelist this, the IPs or hostnames of the smtp server seems the logical step (I have observed two but I could use a regexp). Anyway, I am currently unable to, anything I try does not work and those emails always get rejected. (I have other similar cases).

##
# Helo restrictions
smtpd_delay_reject = yes
smtpd_helo_required = yes
smtpd_helo_restrictions =
  permit_mynetworks,
  warn_if_reject check_helo_access hash:/etc/postfix/helo_whitelist,
  warn_if_reject reject_invalid_hostname,
  warn_if_reject reject_unknown_hostname,
  warn_if_reject reject_non_fqdn_helo_hostname,
  warn_if_reject reject_unknown_helo_hostname,
  warn_if_reject reject_invalid_helo_hostname,
  permit

##
# Sender restrictions
smtpd_sender_restrictions =
  permit_mynetworks,
  check_client_access hash:/etc/postfix/sender_whitelist,
  reject_non_fqdn_sender,
  reject_unknown_sender_domain,
  reject_unknown_address,
  reject_unknown_reverse_client_hostname,
  reject_unknown_client_hostname,
  permit

##
# Recipient restrictions
smtpd_recipient_restrictions =
   permit_mynetworks,
   reject_unauth_pipelining,
   reject_unauth_destination,
   reject_invalid_hostname,
   reject_unknown_hostname,
   reject_unknown_reverse_client_hostname,
   reject_unknown_sender_domain,
   reject_unknown_recipient_domain,
   reject_non_fqdn_hostname,
   reject_non_fqdn_sender,
   reject_non_fqdn_recipient,
   check_sender_access hash:/etc/postfix/sender_access,
   #check_client_access hash:/etc/postfix/rbl_whitelist,
   check_policy_service unix:private/policyd-spf,
   #check_client_access hash:/etc/postfix/rbl_override
   reject_rhsbl_helo dbl.spamhaus.org,
   reject_rhsbl_reverse_client dbl.spamhaus.org,
   reject_rhsbl_sender dbl.spamhaus.org,
   reject_rbl_client zen.spamhaus.org,
   #reject_rbl_client cbl.abuseat.org
   #reject_rbl_client b.barracudacentral.org,
   #reject_rbl_client bl.spamcop.net,
   #reject_rbl_client zen.spamhaus.org=127.0.0.[2..11],
   #reject_rbl_client b.barracudacentral.org=127.0.0.[2..11],
   #check_policy_service unix:/var/spool/postfix/postgrey/socket,
   permit

smtpd_relay_restrictions =
   permit_mynetworks, 
   permit_sasl_authenticated,
   reject_unauth_destination

##
# Data restrictions
smtpd_data_restrictions =
  reject_unauth_pipelining,
  permit

helo_whitelist

mxrelay7.enel.com OK
mxrelay6.enel.com OK

I have tried putting in helo_whitelist the actual HELO hostname smtprelay.enel.com and it doesn't work. I have seen in the docs also the use of PERMIT instead of OK but going through the debug messages (I used debug_peer_list) it looks like it is not correct.

Looking through the debugging though I can see that the reject happens in the recipient address restrictions:

Feb 20 18:41:12 alice postfix/smtpd[1749156]: reject_invalid_hostname: smtprelay.enel.com
Feb 20 18:41:12 alice postfix/smtpd[1749156]: generic_checks: name=reject_invalid_hostname status=0
Feb 20 18:41:12 alice postfix/smtpd[1749156]: generic_checks: name=reject_unknown_hostname
Feb 20 18:41:12 alice postfix/smtpd[1749156]: reject_unknown_hostname: smtprelay.enel.com
Feb 20 18:41:12 alice postfix/smtpd[1749156]: lookup smtprelay.enel.com type A flags
Feb 20 18:41:12 alice postfix/smtpd[1749156]: dns_query: smtprelay.enel.com (A): Host not found
Feb 20 18:41:12 alice postfix/smtpd[1749156]: lookup smtprelay.enel.com type AAAA flags
Feb 20 18:41:12 alice postfix/smtpd[1749156]: dns_query: smtprelay.enel.com (AAAA): Host not found
Feb 20 18:41:12 alice postfix/smtpd[1749156]: lookup smtprelay.enel.com type MX flags
Feb 20 18:41:12 alice postfix/smtpd[1749156]: dns_query: smtprelay.enel.com (MX): Host not found
Feb 20 18:41:12 MYHOST postfix/smtpd[1749156]: NOQUEUE: reject: RCPT from mxrelay6.enel.com[146.133.127.102]: 450 4.7.1 <smtprelay.enel.com>: Helo command rejected: Host not found; from=<[email protected]> to=<MY CLIENT EMAIL> proto=ESMTP helo=<smtprelay.enel.com>
Feb 20 18:41:12 alice postfix/smtpd[1749156]: generic_checks: name=reject_unknown_hostname status=2
Feb 20 18:41:12 alice postfix/smtpd[1749156]: >>> END Recipient address RESTRICTIONS <<<

Question is why the smtpd_recipient_restrictions section should check the helo hostname? Or is it just a delayed check because of smtpd_delay_reject?

Basically, where and how should I put the whitelisted helo messages?

Thanks!

moray avatar
ke flag
Yes of course, this is not the problem.
Score:2
fr flag
anx

You could just delete the duplicated reject_unknown_hostname/reject_unknown_hostname checks, as your helo/ehlo restrictions are applied anyway, as long as you keep smtpd_helo_required=yes.

Then change your list back, whatever is configured with check_helo_access needs to contain the helo values - it is deliberately made to not allow whitelisting with (unverified) host names.


By the way, these are deprecated aliases, always use the current ones that more clearly spell out what is being checked:

reject_unknown_hostname => reject_unknown_helo_hostname
reject_invalid_hostname => reject_invalid_helo_hostname
moray avatar
ke flag
Thanks, for some reasons I didn't catch the duplicates in the helo restrictions. I wonder actually if that was causing the issue as the helo check are deferred for later... Anyway I solved the issue by whitlisting the hosts in check_client_access in the smtpd_recipient_restrictions.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.