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

10

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=<[email protected]> to=<[email protected]> 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
RedLEON
la source

Réponses:

17

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.

cas
la source
Merci. J'ai désactivé ces lignes et ça fonctionne maintenant. Je peux envoyer avec mozilla thunderbird sur mon pc. Mais mon client ne peut pas envoyer de courrier avec des perspectives sur son PC. Existe-t-il un moyen de résoudre ce problème avec la configuration de vérification HELO?
RedLEON
si vous avez supprimé les contrôles hélicoïdaux et que vos clients ne peuvent toujours pas envoyer de courrier, il s'agit probablement d'un autre problème, avec une raison de rejet différente dans le journal de messagerie.
cas
Ils peuvent envoyer maintenant. Mais je veux configurer mon serveur comme sécurisé
RedLEON
2
qu'est-ce qui vous fait penser que les contrôles hélicoïdaux améliorent la sécurité?
cas
8

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
Stas
la source
1

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)

Jason Swartz
la source
0

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

Matt Bird
la source
0

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

Jonas Kvinge
la source
0

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é.

Danny
la source
0

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é.

Jarekczek
la source
0

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.

Nick Coons
la source