À quand remonte la dernière fois que vous avez eu besoin de lire cet e-mail du 15 septembre 2012 ? Ça fait longtemps n’est-ce pas ?
Préambule
Le stockage de ces e-mails n’est pas sans impact énergétique : en effet, les serveurs (gros ordinateurs) qui hébergent ces vieux e-mails sont allumés en permanence pour vous permettre, un jour peut-être, de relire cet e-mail du 15 septembre 2012 dont vous n’avez même plus le souvenir. Deux solutions peuvent s’offrir à vous pour diminuer cet impact :
Supprimer vos vieux e-mails, la solution la plus sobre, radicale ;
Archiver vos e-mails sur une clé USB / un disque dur externe, votre ordinateur ; en tout cas, un système d’archivage « froid », c’est-à-dire qui ne sera pas allumé en permanence.
Un service web et open source pour faire ça
Lighten Mailbox est une interface web qui permet de faire du ménage dans sa boîte mail. Ce ménage se fait soit en supprimant des vieux messages, soit en les téléchargeant au format EML ou HTML/TXT. La sélection des messages se fait par critère de date (début/fin), puis en sélectionnant les dossiers IMAP concernés.
Exemple d’utilisation : Télécharger et archiver (exemple de rendu) ces emails vieux de 2 ans en les enregistrant sur un disque dur externe, puis (quand vous vous êtes assuré de l’intégrité des données) supprimer ces messages.
Thunderbird et Outlook représente une grosse part de marché dans les clients de messagerie. Je m’occupe de plusieurs service de messagerie (pro, asso…) et il est bien commode pour les usagés que « ça tombe en marche » tout seul pour le paramétrage…
A savoir :
Thunderbird chercher les paramètres dans un XML sur http://autoconfig.votredomain.fr/mail/config-v1.1.xml
Outlook cherche l’enregistrement DNS _autodiscover._tcp.votredomain.fr l’url à contacter et ensuite récupère le XML : https://url_donner_dans_le_dns/Autodiscover/Autodiscover.xml
Du coup nous allons rassemblé ces 2 demandes avec un htaccess et un script PHP qui génère le bon format XML fonction de si c’est outlook our thunderbird qui demande…
Pour cela il faut :
Créer un site « autoconfig.votredomain.fr » (ou un alias si vous avez plusieurs site) et faire pointer l’enregistrement DNS bien sûr…
Créer l’enregistrement DNS SRV type :
_autodiscover._tcp.votredomain.fr. 3600 IN SRV 10 10 443 autoconfig.votredomain.fr.
Dans le site autoconfig.votredomain.fr il vous suffit de glisser 2 fichiers à la racine :
Fichier .htaccess contient :
RewriteEngine On
RewriteRule ^Autodiscover/Autodiscover.xml autoconfig-mail.php
RewriteRule ^mail/config-v1.1.xml autoconfig-mail.php
Pour l’association le Retzien.fr (dont je fais parti) j’ai effectué une migration de Plesk 18 vers ISPconfig 3. Plesk avait été mis en œuvre avant mon arrivé car l’administrateur en place connaissait le produit. Mais c’est un produit payant, de plus en plus cher, et pour une association qui a du mal à avoir un équilibre financier c’était difficile à assumer. Plesk est très « beau » et user friendly mais en tant qu’administrateur système je le trouve plutôt opaque (on ne sais pas exactement ce qu’il fait, pas trop de respect des « us et coutumes » de Linux (position des fichiers de config…), ET CE N’EST PAS LIBRE !!!
ISPconfig est libre et propose un script de migration (ISPConfig Migration Toolkit) mais ne supporte pas les dernières versions de Plesk, car le chiffrement des mots de passe n’est plus compatible. Du coup j’ai dû bricoler… Ce bricolage est l’objet de cet article.
Note : ici il n’est question que de la partie mail/DNS et compte client, car c’est la seule fonctionnalité du serveur, les fonctions web n’ont pas été testées.
Installation ISPconfig + Migration Toolkit
Je ne détaille pas ici la procédure d’installation d’ISPconfig 3 et l’usage du « Migration Toolkit » qui sont déjà bien documentés, dans mon cas :
Suite à l’usage du « Migration toolkit », même si le Plesk source n’est pas supporté, je n’ai pas d’erreur mais j’ai plusieurs problèmes que je vais essayer de régler par différents scripts.
Préambules : Les scripts suivants utilisent l’API d’ISPconfig (il faut donc créer un utilisateur distant, dans Système/utilisateur distant). ils doivent donc les lancer depuis le serveur source (Plesk).
Authentification IMAP
Le problème
Il est impossible de se connecter au serveur avec les comptes IMAP. Le log dit :
Error: sql(xxxxxxx@retzien.fr,::1,<MdFia/2k3toAAAAAAAAAAAAAAAAAAAAB>): Invalid password in passdb: crypt() failed: Invalid argument
Effectivement le chiffrement en base est différent :
Mais on va s’en sortir en rusant, en effet Plesk ne crypte/ »hash » pas les mots de passe mais les chiffre :
Crypter / « hasher » : c’est convertir définitivement un chaîne (ici un mot de passe) en un code. Pour savoir si le mot de passe proposé pour l’authentification est bon il faut crypter / « hasher » le mot de passe et le comparer.
Chiffrer : c’est convertir une chaîne (le mot de passe ici) avec une clé, cette fonction est réversible, et qui détient la clé peut donc déchiffrer la chaîne (le mot de passe)
Les mots de passe dans Plesk sont donc « lisibles » pour qui possède la clé de déchiffrement (l’administrateur par exemple ou un hacker qui obtiendrait l’accès au serveur…)
Pour vous en persuader, lancez la commande ci après et vous obtiendrez un beau tableau 1er colonne « émail », 2ème « mot de passe en clair »
/usr/local/psa/admin/sbin/mail_auth_view
Mais pourquoi les mots de passes ne sont ils pas cryptés ?
Plesk propose le support de l’authentification « mot de passe chiffré ». Et cette fonctionnalité est de fait contrainte à avoir le mot de passe en clair sur le serveur car il faut pouvoir le déchiffrer.
ISPconfig ne supporte pas cette fonctionnalité, car qu’il considère que ce serait un trop gros trou dans la sécurité du serveur, et qu’avec le chiffrement de la connexion SSL/TLS ou START/TLS ce n’est pas nécessaire d’en remettre une couche.
Effet de bord important : si vos utilisateurs ont configurés leur client de messagerie en « mot de passe chiffré » il faudra leur faire modifier ce paramétrage (IMAP & SMTP)
De ce que je comprends, cette méthode d’authentification chiffrée avait sa place quand les serveur IMAP/SMTP ne proposait pas de chiffrement de connexion SSL/TLS ou START/TLS.
La solution consiste, sur le serveur Plesk à lancer le script ci-après qui :
Lance la commande Plesk « magique » pour voir les mots de passe déchiffrés
« Parse » le résultat… Se connecte à ISPconfig et change le mot de chaque boîte émail
<?php
/*
* licence Beerware
* By David Mercereau : http://david.mercereau.info
*/
// Plan B : https://www.besuchet.net/2016/06/plesk-11-encrypted-hashed-password-authentication-php-on-psa-database/
// ISPconfig Remote Config
$CONFIG['remoteUser'] = 'retzien';
$CONFIG['remotePassword'] = 'XXXXXXXXXX';
$CONFIG['remoteSoapLocation'] = 'https://192.168.1.64:8080/remote/index.php';
$CONFIG['remoteSoapUri'] = 'https://192.168.1.64:8080/remote/';
$CONFIG['logfile'] = '/tmp/migration-email-password.log';
function toLog($txt, $level) {
file_put_contents($GLOBALS['CONFIG']['logfile'],date("[j/m/y H:i:s]")." - ".$level." - $txt \r\n",FILE_APPEND);
echo "[$level] $txt\n";
}
// Connexion to ISPconfig
$client = new SoapClient(null, array('location' => $CONFIG['remoteSoapLocation'],
'uri' => $CONFIG['remoteSoapUri'],
'stream_context'=> stream_context_create(array('ssl'=> array('verify_peer'=>false,'verify_peer_name'=>false))),
'trace' => 1));
// Login
if($session_id = $client->login($CONFIG['remoteUser'], $CONFIG['remotePassword'])) {
toLog('Login Ok. Session ID:'.$session_id, 'info');
}
# Launch plesk command for auth view in plain text
exec('/usr/local/psa/admin/sbin/mail_auth_view', $out, $return);
if ($return == 0 || $out[0] == null){
foreach ($out as $line) {
$lineExplode = explode('|', $line);
if (isset($lineExplode[1]) && isset($lineExplode[3])) {
$email = str_replace(' ', '', $lineExplode[1]);
$password = str_replace(' ', '', $lineExplode[3]);
# Verification data
if (filter_var($email, FILTER_VALIDATE_EMAIL) && $password != '') {
# mail_user_get
try {
$mail_user_get = $client->mail_user_get($session_id, array('email' => $email));
if (count($mail_user_get) > 0) {
# Update data
$mail_user_get['password']=$password;
$mail_user_get['move_junk']='y';
$affected_rows = $client->mail_user_update($session_id, 0, $mail_user_get[0]['mailuser_id'], $mail_user_get);
if ($affected_rows == 0) {
toLog('No change for '.$email, 'error');
} else {
toLog('Ok for '.$email, 'info');
}
} else {
toLog('email '.$email.' not present in ISPconfig', 'warn');
}
} catch (SoapFault $e) {
echo $client->__getLastResponse();
die('SOAP Error: '.$e->getMessage());
}
}
}
}
}
if($client->logout($session_id)) {
toLog('Logged out.', 'info');
}
?>
IMAP subscriptions
La souscription au dossier IMAP (le fait de voir ou non certains dossiers et/ou d’en cacher d’autres) n’a pas migré, donc si l’utilisateur avait ajouté un dossier IMAP, il ne le voyez plus sur le nouveau serveur, pourtant le dossier est bien là.. c’est fâcheux. Pour corriger ça, lancez ce petit script sur le Plesk (source) :
Ce script ajoute une politique de spam “normal” (modifiable) et récupère les anciennes clefs DKIM générées par Plesk pour les appliquer dans ISPconfig. Ceci pour éviter d’avoir à retoucher au DNS pendant la migration (toujours à lancer depuis le Plesk) :
En sortie le script donne quelques commandes « rsync » à exécuter par un copier / coller direct dans le terminal du serveur source (Plesk) pour synchroniser les données (archives, paramètres…)
Ensuite sur le serveur decdestination (ISPconfig) lancez la commande :
/var/lib/mailman/bin/check_perms -f
Conclusion
La migration c’est bien passée, c’est transparent pour l’utilisateur, à part le problème de « mot de passe chiffré » à « mot de passe normal », qu’il faut faire changer avant la migration de préférence.
Ensuite il faut se connecter à horde en admin (http://horde.chezvous.com/admin/config) et lancer la mise à jours des configurations et des schémas de bases (suivre la procédure à l’écran, c’est du clic clic…).
Si tout c’est bien passé vous devriez avoir un panel d’admin dans ce goût là :
Des dires de Wikipedia : « Sieve est un langage de filtrage du courrier électronique. Il est normalisé dans le RFC 5228. Sieve permet de filtrer sur les en-têtes d’un message qui suit le format du RFC 5322, c’est-à-dire un message Internet typique. »
Sieve c’est très pratique car le filtrage du courrier est effectué au niveau du serveur dès la réception de l’email. Ce qui est presque indispensable quand on utilise plusieurs clients de messagerie (web &/ou desktop). Je vais donc utiliser Managesieve (qui est la partie serveur du protocole) pour Dovecot (projet Pigeonhole).
Actuellement le panel ISPconfig me permet d’éditer les filtres Sieve mais n’utilise pas Managesieve. ISPconfig stock en base (table mail_user_filter) et écrase le fichier à chaque modification.
Je ne souhaite plus passer par ISPconfig pour modifier mes filtres, mais directement par Horde (via Ingo) ou Roundcube (plugin) ou encore par thunderbird (plugin) selon mes besoins.
Installation de Managesieve
Rien de plus simple :
aptitude install dovecot-managesieved
Modifier le fichier /etc/dovecot/dovecot.conf :
< protocols = imap
> protocols = imap sieve
Puis redémarrer le service, le port 4190 doit ensuite être à l’écoute :
Il vous suffit de modifier le fichier ingo/config/backends.php de votre instance horde de la façon suivante :
[...]
/* IMAP Example */
$backends['imap'] = array(
// ENABLED by default
< 'disabled' => false,
> 'disabled' => true,
'transport' => array(
Ingo::RULE_ALL => array(
'driver' => 'null',
'params' => array(),
),
),
[...]
$backends['sieve'] = array(
// Disabled by default
< 'disabled' => true,
> 'disabled' => false,
'transport' => array(
Ingo::RULE_ALL => array(
'driver' => 'timsieved',
'params' => array(
// Hostname of the timsieved server
'hostspec' => 'localhost',
// Login type of the server
'logintype' => 'PLAIN',
// Enable/disable TLS encryption
'usetls' => false,
// Port number of the timsieved server
'port' => 4190,
// Name of the sieve script
< 'scriptname' => 'ingo',
> 'scriptname' => 'filtres',
// Enable debugging. The sieve protocol communication is logged
[...]
Ne faites (peut être) pas ça chez vous
En effet ça ne s’avère pas être forcément la meilleure des solutions :
Il n’est apparemment pas possible d’importer des scripts existants.
Plus embêtant il s’avère que Horde fonctionne presque de la même façon qu’ISPconfig. A savoir qu’il stock en base les filtres et écrase le script sieve (via managesieve quand même) Ce qui me condamne à n’utilise qu’une interface (horde) pour modifier mes filtres :’-(
Bon je m’en contente, il est toujours plus agréable de modifier ses filtres via son webmail (horde) que via le panel ISPconfig.
Modification de la configuration d’OpenDKIM (/etc/opendkim.conf) :
Socket inet:8891@localhost
LogWhy yes
MilterDebug 1
# Log to syslog
Syslog yes
# Required to use local socket with MTAs that access the socket as a non-
# privileged user (e.g. Postfix)
UMask 002
KeyTable /etc/dkim/KeyTable
SigningTable /etc/dkim/SigningTable
ExternalIgnoreList /etc/dkim/TrustedHosts
InternalHosts /etc/dkim/TrustedHosts
Il faut maintenant générer les clefs & ce script va nous y aider :
#!/bin/bash
# Script sous licence BEERWARE
SELECTOR="mail"
REPERTOIRE="/etc/dkim"
DOMAINE=$1
USERDKIM="opendkim"
GROUPDKIM="opendkim"
if ! [ -d "${REPERTOIRE}" ] ; then
echo "Le répertoire ${REPERTOIRE} n'existe pas."
exit 1
fi
if [ -z ${DOMAINE} ] ; then
echo "Vous devez avoir renseigner le domaine en argument du script."
exit 2
fi
if [ -d "${REPERTOIRE}/keys/${DOMAINE}" ] ; then
echo "Le répertoire ${REPERTOIRE}/keys/${DOMAINE} existe déjà... vous devez déjà avoir dû lancé le script."
exit 3
else
mkdir -p ${REPERTOIRE}/keys/${DOMAINE}
fi
opendkim-genkey -D ${REPERTOIRE}/keys/${DOMAINE} -r -d ${DOMAINE} -s ${SELECTOR}
chown ${USERDKIM}:${GROUPDKIM} ${REPERTOIRE}/keys/${DOMAINE}/${SELECTOR}.private
echo "${SELECTOR}._domainkey.${DOMAINE} ${DOMAINE}:${SELECTOR}:${REPERTOIRE}/keys/${DOMAINE}/${SELECTOR}.private" >> ${REPERTOIRE}/KeyTable
echo "${DOMAINE} ${SELECTOR}._domainkey.${DOMAINE}" >> ${REPERTOIRE}/SigningTable
echo "${DOMAINE}" >> ${REPERTOIRE}/TrustedHosts
if [ -f ${REPERTOIRE}/keys/${DOMAINE}/${SELECTOR}.txt ]; then
cat ${REPERTOIRE}/keys/${DOMAINE}/${SELECTOR}.txt
else
echo "Une erreur s'est produite !"
fi
Exemple d’utilisation du script :
$ ./addDkimKey.sh mercereau.info
mail._domainkey IN TXT "v=DKIM1; g=*; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEOxRe2sVbsmDYbnB1pRWdx5U6FgZiwUKRl0gPFmsgPNA035P7gBLmhXrmALeJLZv0n7ARkStoIvl/ZNAbUep/YUgMynW5q2fsh4Pa/q82ocPKRKGLBYTxFDa+tyhG0oi5pzI6d37Ji9M40c5DgD/2QqTfyY5ywLqKG47+HuivJQIDAQAB" ; ----- DKIM mail for mercereau.info
Le script vous sort l’enregistrement DNS a ajouter pour terminer la configuration
On redémarre les services :
$ service opendkim restart
$ service postfix restart
Ajouter des services décentralisés « à la maison » c’est le bien mais à force d’empiler des briques… ça déborde. Et là j’étais à un stade ou la SWAP était un chouilla trop utilisée.
J’avais déjà désactivé ClamAv (anti-virus) pour économiser de la mémoire vive mais ça ne suffisait pas. Mon autre plus gros poste de dépense en RAM était Amavis/Spamassasin. Je me suis donc mis à chercher une alternative ; La plus légère et efficace semble être DSPAM.
Attention : Le fait de remplacer Amavis/Spamassasin va, de fait vous amputer de fonctionnalité administrable par le panel ISPconfig « Stratégie anti-spam », « liste blanche » car Ispconfig ne support pas (encore !?) DSPAM
Préparation
Étant donné que le serveur est déjà en prod j’ai modifié mon script de firewall (iptables) en spécifiant seulement mon adresse IP pour l’accès au SMTP (pour les tests) ça aura pour effet de faire patienter vos emails en file d’attente sur le serveur émetteur quoi que vous fassiez comme bêtise…
5 jours, c’est par défaut le temps d’attente maximal de la plupart des MTA. Vous pouvez donc théoriquement bricoler pendant 5 jours sans perdre d’email dans cet état…
Installation
Je suis sous Debian squeeze, les paquets Dsapm existe pour squeeze mais dans le backport (non activé pour ma part)
Dans mon cas j’ai choisi de tout le temps délivrer les SPAM et de tagger le sujet. L’apprentissage se fera via l’interface web (dont nous verrons la configuration plus tard)
Activer le démarrage de Dspam /etc/default/dspam
< start=NO
---
> start=YES
La configuration de Dspam à largement été inspiré du howto d’UNIX garden :
L’objectif premier était d’économiser de la mémoire vive, c’est chose faite ! la preuve en image :
Je suis aussi très satisfait de l’apprentissage de DSPAM. Au début ça peut faire peur parce qu’il laisse vraiment tout passer, mais l’apprentissage est rapide et significatif :
En continuant à utiliser le site, vous acceptez l’utilisation des cookies (au chocolat) Plus d’informations
Les cookies sont utilisés à des fin de statistique de visite du blog sur une plateforme indépendante que j'héberge moi même. Les statistiques sot faites avec un logiciel libre. Aucune information n'est redistribué à google ou autre. Je suis seul autorisé à lire ces informations