Commande Helo rejetée: besoin d'une erreur de nom d'hôte complet

Mon serveur de messagerie est dans une liste noire à l'origine de spams. J'ai reconfiguré le suffixe. Après cela, mes clients reçoivent cette erreur, ils ne peuvent pas envoyer d'e-mails.

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

Dans 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>

Dans mon 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

Ce message d'erreur s'affiche car le client de messagerie envoie uniquement un nom d'hôte nu ("PLLAMNAZIFE") plutôt qu'un nom d'hôte complet (par exemple "PLLAMNAZIFE.example.com") dans la HELO/ EHLOpartie de la transaction SMTP et votre serveur Postfix est configuré pour rejeter ce courrier.

De nombreux programmes client de messagerie n'envoient pas les noms d'hôte valides correctement formatés, pleinement qualifiés et dans le HELO/ EHLO. Étant donné que vous devez accepter ce type de courrier de clients payants et avoir peu ou pas de contrôle sur le client de messagerie qu'ils utilisent (et parce que les HELOchèques ne sont pas vraiment utiles pour bloquer le spam), il est probablement préférable de désactiver les HELOchèques.

Pour désactiver les HELOvérifications, supprimez les deux lignes suivantes de votre configuration Postfix:

    reject_non_fqdn_helo_hostname,
    reject_invalid_helo_hostname,

Encore mieux, supprimez toute la smtpd_helo_restrictions = ...règle et smtpd_helo_required = yes.

Vous pouvez contourner les restrictions HELO pour les utilisateurs authentifiés en insérant permit_sasl_authenticatedavant de rejeter les règles dans la smtpd_helo_restrictionsliste:

smtpd_helo_restrictions =
    permit_mynetworks,
    permit_sasl_authenticated,
    reject_non_fqdn_helo_hostname,
    reject_invalid_helo_hostname,
    permit

La variable de nom d'hôte pour votre serveur de messagerie n'est pas valide.

Essayez de changer la valeur du myhostnamechamp de /etc/postfix/main.cfla valeur par défaut à votre nom d'hôte (par exemple yourwebsite.comou mail.yourwebsite.com)

Il m'a fallu des siècles pour résoudre ce problème

J'exécute un serveur centos et je recevais des e-mails qui rebondissaient en signalant l'erreur "Commande Helo rejetée: besoin d'un nom d'hôte complet"

J'ai fini par activer "Référence / etc / mailhelo pour le SMTP sortant HELO [?]" Celui-ci se trouvait sous "gestionnaire de configuration exim" puis "Domaines et IPS" sur le serveur VPS

Ensuite, j'ai utilisé du mastic et à distance sur le serveur et j'ai exécuté cette commande "sudo nano / etc / mailhelo"

Dans ce fichier, j'ai créé les domaines example.com: example.com sub.example.com: example.com example.net: example.net addon.example.net: example.net *: hostname.example.com

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

J'ai testé l'envoi d'e-mails et tout va bien jusqu'à présent

Ce n'est pas votre serveur de messagerie qui rejette le client, mais un serveur SMTP externe qui rejette le message de votre serveur SMTP, le problème est que votre serveur SMTP n'envoie pas son nom FQDN dans le message hélicoïdal lors de la communication avec d'autres serveurs.

Cela peut généralement être résolu en ajoutant l'adresse IP publique au fichier hosts avec le nom de domaine complet au fichier / etc / hosts. Comme ça:

1.1.1.1 hôte host.domain.com

127.0.0.2 hôte host.domain.com

Où 1.1.1.1 est l'IP officielle.

J'ai eu ce problème et cela n'a pas aidé que le DNS fonctionne dans les deux sens avant / arrière sur l'IP publique et je n'avais que mon propre serveur de noms dans /etc/resolv.conf. Même le nom d'hôte -f a renvoyé le bon. Je devais encore mettre l'ip et le nom d'hôte dans / etc / hosts pour que sendmail utilise réellement le nom de domaine complet au lieu du simple nom d'hôte.

Si vous telnet à votre serveur sur le port 25, assurez-vous que la ligne 220 indique le FQDN et pas seulement l'hôte. Comme ça:

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

Parfois, un serveur a un «hoquet». Causée par exemple par des attaques de courrier.

Essayez d'abord de redémarrer le serveur. Ensuite, désactivez le courrier du serveur et réactivez-le après 15 secondes.

Parfois, le cmd HELO rejeté est dû au fait que le courrier ne peut pas charger de nouvelles définitions antivirus; comme AmaVis qui est utilisé sur les serveurs Apple. Un redémarrage et hors / sur l'application de messagerie dans le serveur résout ce problème. À votre santé.

J'obtenais un nom non-domaine lors de l'exécution hostname -f. J'ai donc googlé pour aucun domaine dans "hostname -f" . Il s'est avéré que je devais modifier /etc/hostname(je suis sur Debian) pour résoudre le problème. Après que les deux hostname -fet heloutilisaient le nom d' hôte qualifié.

Si vous souhaitez rejeter HELO avec de mauvais noms d'hôte, tout en permettant à vos utilisateurs de pouvoir envoyer même si leurs clients n'envoient pas de FQDN avec HELO, vous pouvez laisser ces lignes en place telles que vous les avez:

reject_non_fqdn_helo_hostname,
reject_invalid_helo_hostname,

Mais assurez-vous qu'ils sont précédés de:

permit_sasl_authenticated,

De cette façon, lorsqu'un de vos utilisateurs s'authentifie, il sera autorisé à envoyer des e-mails indépendamment de la validité de leur commande HELO, et uniquement des connexions non authentifiées (qui ne devraient être que d'autres serveurs SMTP vous relayant le courrier, car vous êtes obligeant évidemment tous vos utilisateurs à s'authentifier, n'est-ce pas?) sera soumis à l'exigence HELO valide.