Quand on déploie un Proxmox Mail Gateway, on se retrouve souvent avec un hostname interne (genre pmg01.lan) qui ne correspond pas au FQDN public attendu par les serveurs SMTP distants.

Résultat ?
Des warnings type :

• Hostname does not resolve to IP
• Reverse DNS mismatch
• ou pire… une réputation qui prend cher.

Bonne nouvelle : pas besoin de changer le domaine interne de la VM pour corriger le EHLO. On peut surcharger proprement le template Postfix utilisé par PMG.

Voici la méthode propre et durable (compatible cluster).

---

🎯 Objectif

Forcer le myhostname (et éventuellement mydomain) utilisé par Postfix pour l’EHLO, sans toucher :

• au hostname système
• au domaine AD interne
• à la config DNS locale

---

🧱 Étape 1 – Créer le dossier de templates personnalisés

Sur le nœud master :

mkdir -p /etc/pmg/templates

---

📄 Étape 2 – Copier le template Postfix par défaut

cp /var/lib/pmg/templates/main.cf.in /etc/pmg/templates/

PMG utilise des templates générés automatiquement.
On va créer une version custom qui sera prioritaire.

---

✏️ Étape 3 – Modifier le template

nano /etc/pmg/templates/main.cf.in

Vers la ligne 22, vous trouverez :

mydomain = [% dns.domain %]
myhostname = [% dns.hostname %].[% dns.domain %]

On remplace par une version personnalisée.

---

🅰️ Cas 1 – Un seul PMG

Si vous avez un seul serveur PMG, la config est simple :

# Custom EHLO configuration
mydomain = domainxyz.net
myhostname = pmg10.domainxyz.net

👉 Ici :

• domainxyz.net = votre domaine public
• pmg10.domainxyz.net = FQDN qui doit correspondre :
  • à l’IP publique
  • au reverse DNS
  • à l’enregistrement A

C’est la méthode la plus propre si vous n’avez pas de cluster.

---

🅱️ Cas 2 – Cluster PMG (multi-nœuds)

Si vous avez plusieurs PMG (par exemple pmg10, pmg11, pmg13), on peut utiliser un SWITCH dynamique basé sur le hostname :

# Custom EHLO configuration (cluster mode)
mydomain = domainxyz.net

[% SWITCH dns.hostname %]
[% CASE 'pmg10' %]
myhostname = pmg10.domainxyz.net
[% CASE 'pmg11' %]
myhostname = pmg11.domainxyz.net
[% CASE 'pmg13' %]
myhostname = pmg13.domainxyz.net
[% CASE %]
myhostname = pmgErreur.domainxyz.net
[% END %]

Avantages :

• Un seul template pour tout le cluster
• Adaptation automatique selon le nœud
• Propre et maintenable

Le CASE final sert de fallback de sécurité.

---

🔄 Étape 4 – Synchroniser la configuration

Ensuite, on force la synchronisation vers les nœuds esclaves :

pmgconfig sync --restart 1

⚠️ Le message :

could not change directory to "/root": Permission denied

est sans importance.

Cela va :

• créer /etc/pmg/templates sur chaque nœud
• synchroniser main.cf.in
• régénérer la configuration Postfix
• redémarrer les services

---

✅ Vérifier que ça fonctionne

Sur un nœud :

postconf myhostname

Puis tester en externe :

telnet votre_ip_publique 25

Vous devriez voir :

220 pmg10.domainxyz.net ESMTP Postfix

---

💡 Pourquoi cette méthode est importante

Modifier directement /etc/postfix/main.cf est une mauvaise idée :

• PMG écrase les fichiers à chaque sync
• Les mises à jour peuvent annuler vos modifs
• Le cluster ne sera pas cohérent

La surcharge via /etc/pmg/templates/ est la méthode propre et supportée.

---

🎯 Bonnes pratiques SMTP

Pour éviter les problèmes de délivrabilité :

✔ FQDN public cohérent
✔ Reverse DNS correspondant
✔ SPF valide
✔ DKIM activé
✔ PTR propre
✔ Certificat TLS correspondant au hostname

---

🏢 Chez DYB

Chez DYB, on met en place des infrastructures mail sécurisées pour PME, cabinets comptables, banques et environnements multi-sites :

• Proxmox Mail Gateway clusterisé
• SPF / DKIM / DMARC avancés
• Protection anti-phishing
• Haute disponibilité
• Monitoring réputation IP

Si vous voulez un audit de votre stack mail ou fiabiliser votre délivrabilité, on en parle 😉