Forum Linux.général Problème avec mon Postfix relais

Posté par  .
Étiquettes :
0
16
juin
2011

Bonjour à tous,

J'aurais besoin de votre aide pour un petit soucis avec mon Postfix relais...

Voici ma configuration : en Interne, j'ai un serveur de mail Zimbra qui gère le domaine @maboite.fr.

J'ai installé un Postfix relais sur une Dedibox (hostname dedibox-maboite) afin que quand on envoie un mail à @maboite.fr, les mails soient envoyés au Postfix de la Dedibox, puis qu'il les relaient à Zimbra. L'avantage de cette infra est que si le serveur Zimbra devient indisponible, le Postfix relais garde les mails en attente jusqu'à ce qu'il soit UP.

Le Zimbra va devenir mail2.maboite.fr, et mail.maboite.fr (utilisé à l'origine) pointera sur la Dedibox.

Bon, voici les DNS actuels :

dig mx maboite.fr :

;; ANSWER SECTION:
maboite.fr.     14400   IN  MX  15 mail2.maboite.fr.
maboite.fr.     14400   IN  MX  20 host1.autre.fr.
maboite.fr.     14400   IN  MX  10 mail.maboite.fr.

Tout me paraît correct. Ensuite, dig a mail.maboite.fr :

;; ANSWER SECTION:
mail.maboite.fr.    14400   IN  A   88.***.***.*** (IP DEDIBOX)

Ça, c'est bon, c'est bien l'ip de la Dedibox.

Et dig a mail2.maboite.fr :

;; ANSWER SECTION:
mail2.maboite.fr.   14400   IN  A   217.***.**.*** (IP publique réseau maboite.fr)

Bref, niveau DNS, tout me paraît correct non ?

Maintenant, ma config Postfix (/etc/postfix/main.cf) :

smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu)
biff = no
readme_directory = no

# TLS parameters
smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
smtpd_use_tls=yes
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

myhostname = dedibox-maboite.dedibox.fr
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
mydestination = dedibox-maboite.dedibox.fr, localhost.dedibox.fr, localhost
relayhost = mail2.maboite.fr
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = loopback-only
inet_protocols = all

Si depuis la Dedibox je fais un telnet localhost 25 avec envoi de mail vers @maboite.fr, le mail pars bien de la Dedibox pour arriver sur le Zimbra.

En revanche, je vois aucun mail passer sur mon Postfix (/var/log/mail.log). Normalement, je devrais voir tous les mails à destination de @maboite.fr puisque mon Postfix est relais. Pourtant non, rien.

Quand j'envoie un mail de mon compte Gmail vers maboite.fr, le mail arrive bien sur le Zimbra, mais niveau log, je ne le vois passer nulle part sur la Dedibox...

Avez-vous une idée ? Peut-être le nom de la Dedibox, ou que sais-je... ?

Merci d'avance pour les courageux qui prendront le temps de me lire.

  • # oubli dans les destinations?

    Posté par  . Évalué à 1.

    bonjour

    sur la config postfix, je ne vois pas mention du domaine maboite.fr sur le parametre "mydestination".
    en bref, la dedibox n'acceptera pas les mails pour le domaine maboite.fr.

    pour moi, un mail venant de l'exterieur essaiera la dedibox, se fera jetter, puis passera a la suite, sur le serveur Zimbra.

    • [^] # Re: oubli dans les destinations?

      Posté par  . Évalué à -1.

      J'ai édité le mydestination :

      mydestination = maboite.fr, dedibox-elisath.dedibox.fr, localhost.dedibox.fr, localhost

      Mais les mails arrivent toujours sur le Zimbra et je les vois pas passer dans /var/log/mail.log

  • # Loopback ???

    Posté par  . Évalué à 0.

    La ligne "inet_interface = loopback-only" me paraît quelque peu suspecte...

    Avec ce paramètre Postfix ne va attendre que les connexions provenant de localhost (donc la dedibox) et ignorera celles provenant de l'extérieur.

    Les mails arrivent donc bien sur zimbra sans passer par la dedibox grâce aux MX secondaires.

    • [^] # Re: Loopback ???

      Posté par  . Évalué à -1.

      Si je mets ceci :

      inet_interfaces = all

      J'ai ce message dans /var/log/mail.log quand je fais un postfix reload :

      Jun 16 12:22:02 dedibox-maboite postfix/master[1572]: warning: service smtp: ignoring inet_interfaces change
Jun 16 12:22:02 dedibox-maboite postfix/master[1572]: warning: to change inet_interfaces, stop and start Postfix

      Mais toujours même problème =/.

      • [^] # Re: Loopback ???

        Posté par  . Évalué à -1.

        Il faut redémarrer Postfix pour prendre en compte la modification.

        • [^] # Re: Loopback ???

          Posté par  . Évalué à -1.

          Arf, je pensais que "postfix reload" suffisait :

          Voici ce que j'ai now :

          myhostname = dedibox-elisath.dedibox.fr
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
mydestination = maboite.fr, dedibox-elisath.dedibox.fr, localhost.dedibox.fr, localhost
relayhost = mail2.maboite.fr
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
#inet_interfaces = loopback-only
inet_protocols = all

          Et quand j'envoie un mail maintenant :

          : NOQUEUE: reject: RCPT from mail.autreboite.eu[88.191.xx.***]: 550 5.1.1 <jeoffrey@maboite.fr>: Recipient address rejected: User unknown in local recipient table; from=<jeoffrey.truc@autreboite.eu> to=<jeoffrey@maboite.fr> proto=ESMTP helo=<mail.autreboite.eu>

          • [^] # Re: Loopback ???

            Posté par  . Évalué à -1.

            Je n'ai jamais utilisé postfix en tant que relais, mais je pense qu'il faut définir les destinataires de ton domaine également au niveau de postfix, et aussi indiquer que les mails à destination de ces destinataires (ça fait quelques répétitions mais c'est pas grave) doivent être renvoyés vers zimbra. Ca doit se définir dans les transports. Il s'agit des paramètres relay_domains et relay_recipient (vu à l'instant en cherchant sur google).

            Le paramètre relayhost est utilisé pour dire à Postfix que les mail envoyés vers l'extérieur doivent être transmis au relais spécifié.

            • [^] # Re: Loopback ???

              Posté par  . Évalué à -1.

              J'ai mis ceci : 

              relay_domains = maboite.fr
relay_recipient_maps =

              Mais j'ai toujours la même erreur =/

  • # Résolu !

    Posté par  . Évalué à 1.

    Problème résolu ! J'avais le "mydestination" en trop...

    myhostname = dedibox-elisath.dedibox.fr
myorigin = /etc/mailname
relay_domains = elisath.fr
relay_recipient_maps =
relayhost = mail2.elisath.fr
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
inet_protocols = all
smtpd_sender_restrictions = reject_unknown_sender_domain

    Merci pour votre aide ;) .

  • # Mauvaise implémentation

    Posté par  (site web personnel) . Évalué à 2.

    L'avantage de cette infra est que si le serveur Zimbra devient indisponible, le Postfix relais garde les mails en attente jusqu'à ce qu'il soit UP.
    Bref, niveau DNS, tout me paraît correct non ?

    Non. On a inventé les MX secondaires pour ça : tu mets deux enregistrements MX, avec ton serveur Zimbra en plus haute priorité et ton serveur Postfix en plus basse priorité. Quand quelqu'un aura un message à te transmettre il essaiera d'abord le Zimbra, puis, s'il est indisponible, le Postfix :

    example.com.   MX 10 zimbra.example.com.
example.com.   MX 20 postfix.example.com.

    Puis tu configures Postfix pour qu'il accepte le courrier en tant que relais intermédiaire. /etc/postfix/main.cf :

    relay_domains = example.com
# Et *surtout pas* example.com dans mydestination !

relay_recipient_maps = hash:/etc/postfix/relay/example.com

    Enfin, dans /etc/postfix/relay/example.com, tu mets la liste des adresses de ce nom de domaine, histoire que ton Postfix en ait connaissance et puisse ainsi refuser directement le courrier à destination d'adresses inexistantes :

    toto@example.com
titi@example.com

    Comme tous les fichiers de tables Postfix, il faut en faire une table hachée :

    # postmap /etc/postfix/relay/example.com

    Plus d'infos : [http://postfix.traduc.org/index.php/STANDARD_CONFIGURATION_README.html#backup].

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.