Ytdyklly

My mail server is in some blacklist cause of spams. I reconfugured postfix. Aften then
My customers get this error they can't send emails.

404 4.5.2 <PLLAMNAZIFE>: Helo command rejected: need fully-qualified hostname

In Mail.log:

postfix/smtpd[9853]: NOQUEUE: reject: RCPT from unknown[xx.xx.xx.xx]: 

404 4.5.2 <PLLAMNAZIFE>: Helo command rejected: need fully-qualified hostname; 

from=<info@domain.com> to=<mail@mail.com> proto=ESMTP helo=<PLLAMNAZIFE>

In my main.cf:

   # rules restrictions

smtpd_client_restrictions =

        permit_sasl_authenticated 

smtpd_helo_restrictions =

        permit_mynetworks,

        reject_non_fqdn_helo_hostname,

        reject_invalid_helo_hostname,

        permit

smtpd_sender_restrictions =

smtpd_recipient_restrictions = 

        permit_sasl_authenticated, 

        reject_unauth_pipelining,

        reject_non_fqdn_recipient,

        reject_unknown_recipient_domain,

        permit_mynetworks, 

        reject_unauth_destination, 

        reject_invalid_hostname, 

        reject_non_fqdn_sender, 

        reject_unknown_sender_domain,

        reject_rhsbl_client blackhole.securitysage.com, 

        reject_rhsbl_sender blackhole.securitysage.com, 

        reject_rbl_client zen.spamhaus.org, 

        reject_rbl_client bl.spamcop.net, 

        reject_rbl_client blackholes.easynet.nl, 

        reject_rbl_client cbl.abuseat.org, 

        reject_rbl_client proxies.blackholes.wirehub.net, 

        reject_rbl_client dnsbl.njabl.org



smtpd_helo_required = yes

unknown_local_recipient_reject_code = 550

disable_vrfy_command = yes

smtpd_data_restrictions = reject_unauth_pipelining

That error message is appearing because the mail client is sending only a bare hostname ("PLLAMNAZIFE") rather than a fully-qualified hostname (e.g. "PLLAMNAZIFE.example.com") in the HELO/EHLO part of the SMTP transaction, and your Postfix server is configured to reject such mail.

Many mail client programs do not send correctly formatted, fully-qualified, valid hostnames in the HELO/EHLO. Since you have to accept such mail from paying customers and have little or no control over what mail client they use (and because HELO checks aren't really of much use in blocking spam), it's probably best to disable the HELO checks.

To disable HELO checks, remove the following two lines from your Postfix config:

    reject_non_fqdn_helo_hostname,

    reject_invalid_helo_hostname,

Even better, remove the entire smtpd_helo_restrictions = ... rule and smtpd_helo_required = yes.

You can bypass HELO restrictions for authenticated users by inserting permit_sasl_authenticated before rejecting rules in the smtpd_helo_restrictions list:

smtpd_helo_restrictions =

    permit_mynetworks,

    permit_sasl_authenticated,

    reject_non_fqdn_helo_hostname,

    reject_invalid_helo_hostname,

    permit

The host name variable for your mail server is invalid.

Try and change the value of myhostname field from /etc/postfix/main.cf from the default value to your host name (e.g. yourwebsite.com or mail.yourwebsite.com)

It has taken me ages to work this out

I am running a centos server and was getting email bouncing back reporting the error" Helo command rejected: need fully-qualified hostname"

I ended up enabling "Reference /etc/mailhelo for outgoing SMTP HELO [?]"
This was located under "exim configuration manager" then "Domains and IPS" on the VPS server

Then i used putty and remoted onto the server and ran this command "sudo nano /etc/mailhelo"

In that file i created the domains
example.com: example.com
sub.example.com: example.com
example.net: example.net
addon.example.net: example.net
*: hostname.example.com

(as per http://docs.cpanel.net/twiki/bin/view/AllDocumentation/WHMDocs/EximDifferentIps)

I have tested sending email and all looks good so far

It's not your e-mail server that rejects the client, but an external SMTP server that rejects the message from your SMTP server, the issue is that your SMTP server does not send it's FQDN name in the helo message when communicating with other servers.

This can usually be solved by adding the public IP to hosts file with the FQDN to the /etc/hosts file. Like this:

1.1.1.1 host.domain.com host

127.0.0.2 host.domain.com host

Where 1.1.1.1 is the official IP.

I had this problem and it did not help that the DNS was working both ways forward/reverse on the public IP and I had only my own nameserver in /etc/resolv.conf. Even hostname -f returned the correct one.
I still had to put the ip and hostname to /etc/hosts for sendmail to actually use the FQDN instead of just the short hostname.

If you telnet to your server on port 25, make sure the 220 line says the FQDN and not just the host.
Like this:

220 host.domain.com ESMTP Sendmail 8.15.2/8.15.2/SuSE Linux 0.8; Mon, 9 Jul 2018 18:19:48 +0200

Sometimes a server has a 'hiccup'. Caused for instance by mail attacks.

First try restart the server.
Than set the mail in the server to off an after 15 seconds back on.

Sometimes the HELO cmd rejected is caused because mail cannot load new anti-virus definitions; like AmaVis that is used on Apple servers.
A restart and off/on the mail app in the server solves this problem.
Cheers.

I was getting non-domain name when running hostname -f. So I googled for no domain in "hostname -f". It turned out I needed to edit /etc/hostname (I'm on Debian) to resolve the problem. After that both hostname -f and helo were using fully qualified hostname.

If you want to reject HELO with bad hostnames, but still allow your users to be able to send even if their clients don't send FQDNs with HELO, you can leave these lines in place as you have them:

reject_non_fqdn_helo_hostname,

reject_invalid_helo_hostname,

But make sure they are preceded by:

permit_sasl_authenticated,

This way, when one of your users authenticates, they'll be permitted to send email regardless of the validity of their HELO command, and only non-authenticated connections (which should only be other SMTP servers relaying mail to you, because you're obviously requiring all of your users to authenticate, right?) will be subject to the valid HELO requirement.