rapatriement messagerie en interne

[Franck78]

Bonjour,


Je vais me lancer sous peu dans une opération sensible encore jamais menée par moi.
En résumé très rapide:

-le POP/SMTP actuel de mon patelin se trouve chez Orange OBS, pack 120 boites.
-tous les clients du LAN pointent donc à l'extérieur,
-mais aussi, quelques postes isolés simplement sur internet.

cette situation ne permet pas d'avoir un véritable groupware, j'ai un joyeux mélange ce clients à entretenir (tbird, outlook, zimbradesktop,outlookexpress,webmail) et biensur aucun partage de carnet d'adresse, de ressources etc, etc.
Et quand voisine A envoie un mail à voisine B dans le même bureau, elle me regarde avec des yeux ronds quand je lui dit que le message fait trois le tour de la terre....c'est pourquoi il faut attendre.


Donc, j'envisage soit OPenXchange, soit zimbra server comme groupware*


Dis comme ca c'est facile. Implémenter la chose est plus complexe. Parceque je ne pourrais pas switcher tout d'un coup (~100 postes, 20 sites).

En imaginant juste le minimum vital postfix+dovecot, premier problème immédiat:
le nom de domaine "ville.fr"
-sur internet, pointe chez OBS (mx)
-en interne, logiquement le postfix gére le même domaine.

1° Voisine A est migrée, écrit a voisine B, mais postfix nr connait pas encore.

-->solutions? usine à gaz? utiliser les tables postfix pour router vers OBS les BAL non migrées

-->avoir un domaine interne 'ville.local' et remapper encore avec postfix
(pas intuitif pour les utilisateurs).

-->un fetchmail résout le cas du monsieur internet écrivant à Voisine A migrée (et oui le mx pointera jusqu'a la fin chez SMTP/OBS), quoique utiliser la redirection proposée par OBS fonctionnerait aussi.


En bref voila, c'est pendant la migration, comment gérer l'existence des BALs sur un serveur ou au autre au mieux sans se prendre la tête....

Si vous avez quelques tuyaux, piège à éviter,....



Merci
Franck



*ce topic n'a pas pour objet le choix du groupware qui sera très surement caché derrière un postfix.

[arapaho]

De prime abord, ça manque un peu de détails:
* la gestion de la zone DNS est-elle possible ?
* les comptes peuvent-ils être relevés en imap sur le MDA actuel ?
* La gestion des dits comptes est-elle centralisée ? Comment la migration de la base utilisateurs est-elle réalisée.
* le niveau critique de la migration

Sinon, brièvement, je pense que la migration peut être réalisée de la manière suivante:
1 - monter la nouvelle infra
2 - changer les enregistrements MX afin qu'il reflètent les nouveaux MTA
3 - migrer les users sur la nouvelle infra. Les enregistrements DNS utilisés dans les paramètres serveurs "entrant" et "sortant" des MUA limiterons les démarches de migration.
4 - réaliser de l'imapsync fréquent entre l'ancien MDA et le nouveau, le temps de la propagation DNS des changements de la zone
5 - une fois la prise de main réalisée sur "l'ensemble mail", la mise en oeuvre du groupware peut commencer.

Evidemment, on peut intercaler la dedans des proxies POP/IMAP, tel que perdition, pour indiquer sur quel MDA tel ou tel user doit relever son mail, etc ...

Tout cela pour faire avancer le fil et obtenir plus de détail

[jdh]

(Hors groupware, j'ai testé récemment iRedMail : c'est simple, efficace et vraiment rapide pour créer un bon système d'hébergement avec tout ce qu'il faut. Sinon Zimbra est aussi aisé à installer quoique lourd et avec des mises à jour peut-être trop fréquentes.)

(Il y a 6 mois, j'ai basculé 130 boites mail en 2 domaines de O. à S. avec l'aide du week-end ! La principale difficulté a quand même constitué à reconfigurer les clients.)


Le premier point, c'est de récupérer la gestion du domaine, quitte à indiquer le(s) MX existant(s). C'est assez aisé et sans difficulté.

Je peux imaginer que les clients lourds sont en mode client pop3 avec serveur pop "pop.o.fr" et serveur smtp "smtp.o.fr". Donc, outre la migration des MX, il faut prévoir la reconfiguration des clients lourds. Il faudra aussi prévoir de passer éventuellement par un smtp-authentifié (SMTP-AUTH sur port 587/tcp) pour éviter les problème de filtrage des box.

Le deuxième point est de construire le serveur "qui va bien", avec les fonctionnalités nécessaires ainsi que de résoudre les nécessités d'un hébergement "interne" (adresse ip fixe, MX backup, ptr reverse sur ip, sécurisation du serveur, ...).

En troisième point, il faut créer pop. et smtp. pointant vers le serveur, puis basculer le MX, de préférence un vendredi soir.

Le dimanche soir, il faut récupérer les mails restants par un fetchmail (boite de réception seule) ou un imapsync (O. est normalement accessible en imap).

Le lundi matin, il faut reconfigurer chaque client (et se faire aider). Quelques tutos de config sont à réaliser selon le client lourd ...

(Le mercredi, on peut faire péter les bouchons ...)

Plus ou moins ...

[Franck78]

ok,

le DNS est chez orange/oléane, pas encore cherché à y accéder. Si problème, transfert chez AMEN ou un autre.

La gestion du spam n'étant pas forcément très compliquée mais dévoreuse de temps que je n'ai pas, je pense vraiment externaliser le service MX+backup MX 'hors de chez moi' et récupérer les mails 'tagués' spam/virus dans le SMTP interne.

Ce qui n'empèche nullement d'avoir un smtp2.ville.fr pour mes machines hors LAN (ecoles, crèches,...) authentifié.

Migrer tout le monde un weekend, c'est pas possible. Trop de cas particuliers à géré. A commencé par les utilisateurs réfractaires à tout (migrer=récup messages actuels tout format sous zimbra/Ox).

Par contre déplacer le SMTP/POP en une journée, oui. Suffit de corriger le dns local.
Finalement cela serait plus simple que prévu
1)rapatriement du SMTP/POP en interne, perte de outlook webaccess pas grave.
2)mise en place du groupware et migration au fur et à mesure.

@arapaho, je maitrise les noms de comtpes/email et mots de passe chez OBS
En interne, il est tentant de lier postfix et active directory. Tentant seulement car le turnover est faible. Du coté utilisateur, ils sont loin de savoir que SSO existe.

DNS: il y a très longtemps, j'avais lu un papier décrivant très précisément comment gérer le problème du temps de propagation. De mémoire, en prend le TTL actuel de la zone que l'on divise par deux, on attend la durée du TTL précédent, on recommence jusqu' atteindre un temps raisonnable le jour de la migration. Pour je ne sais plus quelle raison il faut éviter de passer de 1 semaine à 1 minute en une fois! Mais bon, c'est ancien.

[jdh]

A partir du moment où tu bascules le MX puis tu vides les anciennes boites par fetchmail, peu importe le temps nécessaire à modifier les clients lourds : ils ne reçoivent plus rien (et sans message d'erreurs), ils émettent toujours et, toi, tu reçois normalement sur ton serveur. Donc cela permet d'étaler le parcours de tous les pc (sauf qu'ils raleront de ne pas recevoir leur mails !).

Je trouve que construire un serveur mail qui réceptionne et qui fait les nécessaires analyses AV/AS de façon propre et efficace, c'est assez difficile à bien réussir. D'où l'intérêt de solutions clés en main type iRedMail ou Zimbra : cf howtoforge qui recense pas mal de solutions de ce type en "tout en un". (iRedMail fournit comme webmail RoundCube qui est largement plus agréable que le vieux Squirrelmail, d'autant qu'il est facile de remplir le carnet d'adresse de RoundCube pour chaque utilisateur = table MySQL).

La solution cible se monte (et se teste) AVANT ! Le tableau des users/mots de passe peut très bien servir à alimenter la base utilisateur du nouveau système. Pourquoi un transfert (O. vers interne) puis une migration (interne1 vers interne2).

Si les users restent avec un client lourd de leur choix, la migration pop3 vers imap, avec réinjection des mails reçus devient très longue mais peut montrer qu'un changement de client est ensuite aisé ! Attention à penser quotas avant de choisir une solution de groupware et sizer correctement le serveur ! (Moi je suis cuit sur cet aspect : il y a des users qui remplissent les 4 Go max d'un .pst).

Zimbra offre l'intérêt d'un client lourd équivalent au webmail mais Java à tous les étages ...

eGroupware présente l'intérêt de reposer sur un messagerie imap au choix. Je peux penser qu'iRedMail+eGroupware doit aller vite à s'installer ...


Je ne me suis même pas occupé de regarder/gérer la migration de dns (et jouer sur les ttl, si je suis ta technique on doit pouvoir migrer sans difficulté en 2x le ttl d'origine ?).