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.
- 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 NeoX . Évalué à 3.
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 X345 . Évalué à 3.
Maintenant, si ce que je veux faire est vraiment tordu, j'opterai pour cette solution.
# Mon petit cas personnel
Posté par Honor (site web personnel) . Évalué à 3.
[^] # Re: Mon petit cas personnel
Posté par X345 . Évalué à 1.
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 Honor (site web personnel) . Évalué à 1.
# Solution retenue au final
Posté par X345 . Évalué à 2.
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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.