Forum Linux.général Exim : Serveur mail secondaire "cache"

Posté par .
Tags : aucun
1
8
avr.
2010
Bonjour,

J'ai quelques questions sur la configuration d'Exim en tant que MX secondaire "amélioré", vu que ça peut sembler assez incongru, je vais essayer de présenter la situation pour que ce soit plus clair.

Situation actuelle

Version détaillée
J'héberge (enfin j'essaie !) mon serveur de mail (configuration classique Debian+Exim) derrière une connexion ADSL. Comme il y a pas mal de problèmes dans ce genre de configuration (carte SD qui sert de root capricieuse, coupures d'électricité, déconnexions etc...) j'ai un petit serveur dédié virtuel sur lequel j'ai installé un exim secondaire. J'ai laissé une configuration de "base" (ajout du domaine au relay_domains) donc en gros le serveur secondaire se contente de garder le message dans sa file d'attente et essaye de le renvoyer au serveur primaire jusqu'à ce que ce dernier marche à nouveau.

En résumé
  • Serveur MX principal: Derrière connexion ADSL (pas mal d'indisponibilités) / Configuration Exim+Debian simple (distribution dans $HOME/Maildir)
  • Serveur MX secondaire: VPS / Configuration Exim en relay de base (garde le message en file d'attente et essaye de le redonner au principal)

Problème
Ben, c'est très simple, je suis pas toujours chez moi donc quand le serveur principal tombe en rade, je n'ai pas toujours les moyens de résoudre le problème. Ce qui fait que je peux pas lire mes mails. Ils ne sont certes pas perdus, mais ils restent dans la file d'attente du secondaire, et c'est VRAIMENT pas pratique pour les lire !

Solution envisagée
Configuration du secondaire (VPS), pour chaque message entrant a destination d'un relay_domain:
  • Délivrer le message dans /var/mail/$nom_domaine_backupé/$nom_compte
  • Garder le message dans la file d'attente, et tenter de le délivrer au MX primaire
  • De cette manière, j'ai une sorte de "cache" sur le MX secondaire, ce qui me permet de consulter mes mails le temps qui je remette d'aplomb le primaire.
Questions
  • Est-ce que c'est vraiment tordu/inutilement compliqué comme configuration ? Si oui, qu'est ce que vous me conseillez de faire ?
  • Comment implémenter çà au niveau des routers d'exim (Attention, c'est la question fondamentale de ce post ! :-)) : Je pourrais faire un router de ce style :

    relay_cache:
    driver = accept
    unseen
    domains = +relay_hosts
    transport = relay_cache_delivery

    (sachant qu'il faudrait mettre se router avant le router dnslookup). Comme çà le message serait stocké/mis en cache et continuerait à parcourir les routers (option unseen). Le problème est que si le MX principal est en rade, le message va rester dans la file d'attente et repasser dans les routers indéfiniment. Je vais donc me retrouver à livrer en local 150 fois le même message sur le secondaire...
  • J'aurais surement besoin de faire du ménage dans le boites mise en cache, du fait que beaucoup de spam passe les MX secondaires, même lorsque le principal fonctionne bien. Y'a-t-il un utilitaire pratique pour gérer les boites maildir (genre ne garder que les 100 messages les plus récents)

  • Je suis désolé pour le style un peu directif/militaire du message, mais j'ai pas trouvé mieux. C'est le seul moyen que j'ai trouvé pour ne pas que ça se transforme en bouillie incompréhensible (déjà que ce doit être pas mal fouilli).

    Merci de m'avoir lu :-).
  • # a part la beauté du geste

    Posté par . Évalué à 3.

    pourquoi tu fais pas simplement ton MX primaire sur ton VPS ?
    ainsi tu as une solution qui tourne 24/24 (garantie par le fournisseur)

    et si vraiment tu veux tes emails en local, tu prendre un fetchmail/procmail pour les mettres dans ton serveur local
    • [^] # Re: a part la beauté du geste

      Posté par . Évalué à 3.

      Ahah, je me doutais que j'allais avoir commentaire :D. J'ai oublié d'ajouter une petite note à la fin du post. Je préfère vraiment avoir le MX principal chez moi : internet pas minitel 2.0 tout çà, et puis j'admets que c'est aussi un peu pour la beauté du geste :-).

      Maintenant, si ce que je veux faire est vraiment tordu, j'opterai pour cette solution.
  • # Mon petit cas personnel

    Posté par (page perso) . Évalué à 3.

    Je suis à peut prêt dans la même problématique (MX primaire sous mon canapé), et je l'ai à peut prêt résolu en faisant :
    1. MX primaire qui délivre le mail dans son spool /var/spool/mail/$user accessible par IMAP
    2. MX secondaire qui délivre le mail dans son spool /srv/d_Mnemosyne/mail/$useraccessible par IMAP
    3. un fetchmail tournant sur le MX primaire qui prend les mails du MX secondaire pour les donner au MX primaire
    Cela me permet de partir en vadrouille tranquille, en ayant juste des configurations exim simple...
    • [^] # Re: Mon petit cas personnel

      Posté par . Évalué à 1.

      Merci de ton retour d'expérience, on est exactement dans la même situtation
      Ok, donc si j'ai bien compris, ton MX secondaire est paramétré presque comme un MX primaire (prend les mails pour le domaine pour lequel il est configuré et les délivre en local) et tu utilises fetchmail pour "synchroniser" tes boites mails locales.
      Est-ce que tu as recréé tous les comptes utilisateur sur le MX secondaire (ce qui facilite bien la gestion des droits d'ailleurs...) ou tu as viré la précondition check_local_user dans le router qui s'occupe de la livraison locale ? Du coup, est-ce que tu as trouvé une solution pour éviter de recevoir des mails même pour des utilisateurs qui n'existent pas (verification si le dossier /srv/d_Mnemosyne/mail/$user existe?) ?

      Bon, si je n'arrive pas à faire marcher la configuration que j'ai proposé plus haut (qui présente l'avantage de faire repasser le mail par le MX primaire, qui est mieux configuré :-)), je vais opter pour cette solution.
      • [^] # Re: Mon petit cas personnel

        Posté par (page perso) . Évalué à 1.

        Est-ce que tu as recréé tous les comptes utilisateur sur le MX secondaire (ce qui facilite bien la gestion des droits d'ailleurs...) 
        
        Oui j'ai recréé mes comptes utilisateurs sur le MX secondaire (comme j'en ai très peu). Je m'amuserais peut être à faire une réplication par LDAP, mais pour le moment, j'ai plus envie de cuisiner que de faire du LDAP...
  • # Solution retenue au final

    Posté par . Évalué à 2.

    Bon finalement, la solution que j'envisage dans le post initial fonctionne parce que quand exim met en "retry" un message au niveau d'un router ou d'un transport, ce message ne repasse pas dans la chaine complète de routers. Il reprend là dans le router/transport où il s'était arrêté (ce qui est assez logique au final).

    Si jamais y'en a que ça intéresse (ou toi lecteur qui verra cette page au hasard d'une requête google dans un an :-D), voilà les détails (intéressants de la configuration).
    Pour chaque domaine dont on veut être le MX secondaire:
    - On crée (éventuellement) un fichier d'alias dans /etc/exim/domains_secondary_aliases/$nom_domaine (Peut juste être une copie du /etc/aliases du MX principal qui gère le domaine)
    - On crée un dossier dans /var/mail/domains_secondary/$nom_domaine, puis un sous-dossier par utilisateur (dans le dossier là). Toutes les boites mails sont la propriété de mail:mail
    - Il reste a configurer le serveur POP/IMAP pour authentifier les utilisateurs sur un fichier de mots de passe/base de données.

    Voici les routers exim utilisés :
    Ces routers sont a placer AVANT celui qui gère la redirection vers un serveur SMTP externe (dnslookup en général)

    Le premier gère les alias pour chaque domaine. (ex: toto_la_follette@mondomaine.net est un alias pour thomas@mondomaine.net). On utilise un routeur redirect avec pas mal de restrictions : on veut juste autoriser la possibilité de faire des alias sur les adresses mail (pas de filtres, pas de redirection directe vers un pipe, pas de livraison directe) pour éviter qu'il y ait des conflits entre les fichiers d'alias de tous les domaines.

    domains_secondary_aliases:
    ## Address rewrite no need to use unseen
    driver = redirect
    allow_defer
    allow_fail
    no_allow_filter
    domains = dsearch;/etc/exim/domains_secondary_aliases
    debug_print = "R: domains_secondary_aliases for $local_part@$domain found: ${expand:${lookup{$local_part}lsearch*@{/etc/exim/domains_secondary_aliases/$domain}}}"
    data = ${expand:${lookup{$local_part}lsearch*@{/etc/exim/domains_secondary_aliases/$domain}}}
    retry_use_local_part
    qualify_preserve_domain
    # You want to keep the same not to mix up different domains
    forbid_file

    Le second router correspond a celui qui délivre effectivement une copie du mail dans /var/mail/mondomaine.tld/mon_utilisateur. La seule option importante de ce router est unseen qui permet de faire en sorte que le message ne sorte pas de la chaine de routers à ce moment et reste dans la file d'attente pour éventuellement être transmis au MX primaire.

    domains_secondary_domains_cache:
    unseen
    # Keep the message in spool, we also want to redirect it to the primary MX
    driver = redirect
    allow_defer
    allow_fail
    domains = dsearch;/var/mail/domains_secondary
    debug_print = "R: domains_secondary_domains_cache for $local_part@$domain found: /var/mail/domains_secondary/$domain/$local_part/"
    data = /var/mail/domains_secondary/$domain/$local_part/
    directory_transport = address_directory
    pipe_transport = address_pipe
    file_transport = address_file
    user = mail
    group = mail


    Du coup, si jamais y'en a que ça intéresse, je peux fournir un mini-service de MX secondaire (rajouter un domaine prend 10 secondes).

Suivre le flux des commentaires

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