web-dev-qa-db-fra.com

Commande Helo rejetée: hôte introuvable - Configurer le suffixe pour accepter l'envoi de mails depuis mon serveur domestique via mon serveur public

Je souhaite recevoir des e-mails système de mon serveur domestique. J'essaie donc de configurer postfix pour le faire via mon serveur public. Mon serveur public a une IP fixe, tandis que mon serveur domestique est dans un réseau privé avec un nom d'hôte foiré car le nom d'hôte de mon routeur est inclus dans le nom d'hôte, conduisant à un nom d'hôte complet "homeserver.blablabla_crappyrouter".

Mon serveur domestique se connecte à mon serveur public via un tunnel OpenVPN avec IP fixe où mon serveur domestique est un client. De mon serveur domestique à mon serveur public (et vice-versa), il y a une adresse IP fixe, afin qu'ils puissent se rejoindre sans problème via une adresse fixe. Il s'agit d'un tunnel qui me permet d'accéder à mon serveur domestique de n'importe où sans aucun problème de sécurité.

Ma configuration postfix sur mon serveur public comprend les éléments suivants:

smtpd_recipient_restrictions = reject_invalid_hostname,
        reject_unknown_recipient_domain,
        reject_unauth_destination,
        reject_rbl_client sbl.spamhaus.org,
        permit

smtpd_helo_restrictions = reject_invalid_helo_hostname,
        reject_non_fqdn_helo_hostname,
        reject_unknown_helo_hostname

smtpd_client_restrictions = reject_rbl_client dnsbl.sorbs.net

Et sur mon serveur domestique, j'ai ajouté l'adresse IP du serveur public de mon OpenVPN en utilisant

relayhost = [<public server IP through OpenVPN>]

Maintenant, cette configuration n'envoie pas d'e-mails et me donne l'erreur:

Commande Helo rejetée: hôte introuvable

J'ai fait des recherches à ce sujet et j'ai découvert que postfix recherchait le nom d'hôte, mais apparemment, il ne le trouve pas en raison de son nom d'hôte foiré.

Ma question: Comment puis-je dire au suffixe de mon serveur public d'autoriser aveuglément tout depuis mon serveur domestique?

Merci.

MISE À JOUR:

J'ai défini l'option dans main.cf

smtpd_helo_required = no

mais cela n'a pas aidé. Voici les entrées /var/log/mail.log juste après avoir envoyé un e-mail de test:

Sep  2 15:53:53 HomeServer sm-mta[6677]: t82Drr6w006677: [email protected], size=69, class=0, nrcpts=1, msgid=<[email protected]_crappyRouter>, proto=ESMTP, daemon=MTA-v4, relay=localhost [127.0.0.1]
Sep  2 15:53:53 HomeServer sm-mta[6679]: STARTTLS=client, relay=mydomain.com., field=cn_subject, status=failed to extract CN
Sep  2 15:53:53 HomeServer sm-mta[6679]: STARTTLS=client, relay=mydomain.com., field=cn_issuer, status=failed to extract CN
Sep  2 15:53:53 HomeServer sm-mta[6679]: STARTTLS=client, relay=mydomain.com., version=TLSv1/SSLv3, verify=FAIL, cipher=ECDHE-RSA-AES256-GCM-SHA384, bits=256/256
Sep  2 15:53:53 HomeServer sm-mta[6679]: t82Drr6w006677: [email protected], delay=00:00:00, xdelay=00:00:00, mailer=esmtp, pri=120069, relay=mydomain.com. [93.186.192.197], dsn=4.7.1, stat=Deferred: 450 4.7.1 <HomeServer.blablabla_crappyRouter>: Helo command rejected: Host not found

Le courrier que j'essaie d'envoyer est:

ehlo localhost
mail from: [email protected]
rcpt to: [email protected]
data
Subject: My first mail on Postfix

Hi,
Are you there?
regards,
Admin
.
quit

et je l'envoie en utilisant la commande:

cat mail.txt | nc localhost 25
emailpostfixemail-serveropenvpntunnel
8
The Quantum Physicist

Voici le problème:

smtpd_helo_restrictions = reject_invalid_helo_hostname,
    reject_non_fqdn_helo_hostname,
    reject_unknown_helo_hostname

Le dernier de ceux-ci, reject_unknown_helo_hostname, indique à Postfix de rejeter le courrier si le nom d'hôte donné dans la commande HELO ne peut pas être résolu. Si vous supprimez cela, votre problème devrait disparaître.

Vous devez annuler la modification que vous avez effectuée (paramètre smtpd_helo_required à no). Cette modification a permis à un client de se connecter et de commencer à envoyer des e-mails sans faire d'HELO - mais si le client fait un HELO, les restrictions de smtpd_helo_restrictions s'appliquerait toujours, comme vous l'avez constaté.

7
Jenny D

Vous pouvez modifier votre politique HELO en:

smtpd_helo_restrictions = 
    permit_mynetworks,
    reject_invalid_helo_hostname,
    reject_non_fqdn_helo_hostname,
    reject_unknown_helo_hostname

... et ajoutez l'adresse de votre serveur de messagerie domestique à mynetworks = ... ligne.

Bien que la réponse de @JennyD soit valide et devrait résoudre votre problème, il peut être préférable de conserver votre politique HELO actuelle pour les hôtes externes. Cela a un avantage: les MTA mal configurés ne pourront pas envoyer de messages à votre serveur, ce qui vous évitera un peu de spam (bien qu'un peu). Quoi qu'il en soit, les hôtes avec une configuration HELO incorrecte sont à suspecter.

Pour aller un peu plus loin, assurez-vous d'avoir au moins rejeter_unknown_client_hostname parmi la liste sous ie. smtpd_client_restrictions = .... Cela empêchera les messages des hôtes MTA sans enregistrement DNS inverse approprié et donc de nombreux relais de botnet. Une autre mesure antispam importante serait le démon de politique SPF (ie. milter-greylist) et, évidemment, SpamAssassin.

8
sam_pan_mariusz

Si vous n'avez pas de contrôle précis sur les clients, vous devez quand même utiliser SASL:

smtpd_delay_reject = yes

smtp_helo_restrictions =
    permit_sasl_authenticated,
    reject_unknown_helo_hostname

Cela permet aux hôtes authentifiés SASL d'envoyer un hélicoptère sans restriction

Notez que dans certaines configurations, master.cf définit smtp_helo_restrictions pour submission et smtps vers $mua_helo_restrictions, dans ce cas, définissez mua_helo_restrictions au lieu.

1
nyet