Outils pour utilisateurs

Outils du site


emails

Les objectifs

Je veux que mon serveur reçoive le courrier de mes boites emails. Je pourrai ensuite les consulter depuis un gentil MUA (comme mutt, installé aussi sur le serveur, mais aussi sur mes machines à usage courant, à voir).

Je veux aussi pouvoir envoyer des emails sans avoir à lancer un MUA lourd, donc directement via mutt, ou bien via un script shell.

Je veux pouvoir utiliser les serveurs SMTP existants de mes boites emails. Et je veux aussi disposer d'un serveur SMTP qui servira à mes comptes mails qui n'ont pas de serveur SMTP associé.

Je veux aussi pouvoir déplacer les emails d'une boite IMAP vers une autre boite IMAP, de façon régulière.

Choix des outils

  • mutt
  • fdm
  • msmtp
  • ripmime
  • bash
  • postfix?
  • bogofilter

En pratique

Pour le moment,

  • msmtp fonctionne avec quelques serveurs SMTP configurés. Foirage avec celui de Free.FR en mode authentifié, mais c'est pas grave.
  • fdm fonctionne ! (après debugging d'une fuite mémoire, et un soucis de maximum-size par défaut ajusté trop bas)
  • mutt fonctionne, il chiffre et déchiffre avec GPG, la selection du bon serveur SMTP fut un peu laborieuse mais fonctionne, j'accède à mes inboxes. Par contre, un cas d'usage non satisfait : la modération des listes «Sympa».
  • ripmime fonctionne pour trier les pièces jointes contenues dans les emails

Je n'ai à ma disposition aucun outil pour récupérer les valeurs précises des headers d'un email. J'ai eu besoin de récupérer la valeur de “From:” pour faire du tri de pièces jointes, c'est faisable avec sed et une regexp, mais le résultat n'est pas parfait (expl: hotmail envoie des entêtes From: qui sont réparties sur plusieurs lignes).

Il est dommage que fdm n'ait aucune fonction qui vise à extraire ces valeurs. Voir si GNU mailtools fait mieux, mais il serait dommage d'installer les 2 car ces outils semblent faire double emploi.

fdm fait appel à ripmime pour extraire les pièces jointes. Il a fallu une bonne dose d'écriture de scripts shell pour, d'une part, extraire les pièces jointes depuis les emails existant (stockés dans des maildirs), d'autre part, pour invoquer ripmime lors du rappatriement de nouveaux emails par fdm.

Les scripts que j'ai écrit sont à peu près propres, je les publierai.

Je parlais d'une fuite de mémoire avec fdm, elle arrive quand on transvase depuis une boite IMAP vers une autre. Un petit patch (qui déplace un “free()” vers un autre endroit du code) résoud le problème, mais n'est pas intégré dans les dépots Debian (changelog paquet fdm). J'ai créé un .deb qui intègre le patch pour mes besoins, mais le mieux serait de prévenir le mainteneur Debian pour mettre à jour.

Ce qu'il me reste à faire : configurer quelques boites email collectives, dont je ne dois pas effacer les emails distants.

Avis sur la solution retenue

Mutt est un peu austère à l'usage, peut-être qu'en soignant certaines touches d'accès ça irait mieux (mais ça va quand même). Mutt dirige fortement la façon dont on gère ses emails : il faut une INBOX presque vide. Aussi, il vaut mieux rappatrier les emails plutôt que de les consulter sur les boites distantes via IMAP. Il m'a aussi incité à ne pas avoir de boites emails dans des sous-répertoires. On appréciera qu'il tourne dans un terminal et soit léger en consommation de ressources, il n'est pas lent. Mutt n'est de base pas avare pour ce qui est de vous demander de saisir des touches, un effort est nécessaire pour le configurer et éviter d'avoir à en frapper certaines. Certains hooks aident à cette tâche et sont là pour répondre à des cas de figure, qui sont donc aussi ajoutés au fil de l'utilisation…

Fdm, j'ai trouvé ça franchement sportif.

  • On fait des erreurs, surtout dès qu'on planche sur l'archivage et qu'on joue avec les “keep”… on se retrouve avec des emails en double, disséminés partout. Toujours fastidieux de revenir en arrière.
  • Pas toujours facile de trouver la petite instruction qui fait ce qu'on souhaite. Parfois, elle est même absente (aucun tag pour récupérer le champ From des headers ?).

Fdm est un outil de rappatriement et filtrage d'emails assez complet. Les regexp font tout le boulot de tri. Il peut en outre renvoyer les emails vers un compte IMAP distant. La meilleure source d'info est le fichier MANUAL fourni avec le logiciel, ne cherchez pas trop sur le web ni dans le man. Sa syntaxe est plutôt claire et bien faite quand on l'a intégrée. L'un des points cruciaux de sa configuration est l'écriture des règles matches, car l'ordre d'écriture définit l'ordre d'exécution. Si l'on joue avec plusieurs comptes (dont des maildirs, en plus des IMAPs), il peut arriver qu'on se mélange les pinceaux et que des emails soient traités 2 fois, ce qui peut provoquer le chaos dans vos répertoires et vos emails. Cela nécessite donc de nombreux tests à blanc (avec l'option “keep”), et de faire des copies de sauvegarde *systématiques* lorsqu'on chamboule un truc. Il lui manque peut-être quand même quelques “tags”, comme “From” ou le “Folder” duquel est issu l'email. On parcourt donc parfois le manuel en quête de la petite instruction qu'on aurait loupé, mais en vain… Nécessite aussi d'écrire une paire de scripts pour initier les fetch, varier les cas de figure (activer le debug, (dés)activer tel ou tel compte…). L'outil est quand même bien pensé et semble suffisamment pérenne, à défaut de connaître les autres solutions, pas de regret.

La gestion des pièces jointes est un autre problème. Normalement, mutt sait les gérer, et fait appel au bon programme (voir aussi le fichier “mailcap”) quand on cherche à les visualiser au sein de l'email. Mais dans mon cas, mutt s'exécute sur un serveur distant sans Xorg. Si je veux regarder une photo dans un email, je ne peux pas.

Mes options sont donc : installer mutt localement. Ou bien rappatrier les pièces jointes via un script externe. C'est cette dernière que j'ai choisie, en utilisant ripmime comme ami.

Ripmime sera appellé par fdm pour chaque courrier rentrant. Au préalable, une autre étape est de traiter l'ensemble de mes emails déjà archivés. Le traitement est sommaire. Ripmime ne comprend pas les entêtes (headers) contenues dans les emails. Par contre, il sait découper le contenu Mime du corps du mail. Avec quelques options, on parvient à lui dire de ne pas créer de pièces jointes superflues (non nommées), et un script bash avec find permettra de terminer le nettoyage des autres pièces jointes jugées superflues.

Doc / Liens

Général

msmtp

fdm

mutt

histoires de smtp multiples

ripmime

heirloom-mailx

Autres outils

mutt

reply-to-list par défaut

Répondre avec R, mais ici il faut répondre avec L. S'il détecte que c'est une liste, ce serait bien que le R se transforme en L par défaut.

ajuster From selon account lors d'un reply

Quand je reçois un mail et que je réponds, le From est réinitialisé. J'aimerais qu'il se fie, soit au “To:” (pas valable dans tous les cas) ou de façon plus fiable à une entête personnalisée (account fdm) pour régler le From.

Confirmation d'envoi, et changement de rep c'est la même touche

'y'

Dans un message transféré

On peut vouloir répondre à la personne à l'origine du message (pas à la personne qui transfere). Pas de moyen simple de récupérer cette adresse.

et les listes «sympa»

Pas moyen de valider/refuser simplement un message au sein de mutt.

La solution suggérée est de balancer le message dans un pipe.

# macro index "~/bin/sympa-request.sh ACCEPT"
# macro index "~/bin/sympa-request.sh REJECT"

LINE=(grep -E '^DISTRIBUTE .*$' /dev/stdin)
ACTION=$LINE[1]
LIST=$LINE[2]
KEY=$LINE[3]

if [ $1 ] ; then
    ACTION=$1
fi

echo "" | mail -s "$ACTION $LIST $KEY" sympa

Plantage lors de l'usage de PGP

Mutt par Debian vient avec des scripts pour PGP. Cependant, ça plante souvent… juste avant d'envoyer l'email, on perd le brouillon et tout, bien chiant.

Voilà le scénario : on écrit le mail, on choisit “Ok je chiffre” (P puis C). Il nous demande la clé du destinataire, on laisse vide. Il nous propose la liste de l'ensemble des clés à disposition. On en choisit une (qui ne correspond pas tout à fait au mail du destinataire), et paf mutt plante, retour au shell.

D'abord, je cesse de le faire tourner dans un screen. Ensuite je me rend compte que ça fait un segfault. Bon ben youpi, y'a plus qu'a lancer gdb dessus ?

Problème de locale avec mplserv, mutt ...

Posts utiles :

Via SSH:

# locale
LANG=
LANGUAGE=
LC_CTYPE="POSIX"
LC_NUMERIC="POSIX"
LC_TIME="POSIX"
LC_COLLATE="POSIX"
LC_MONETARY="POSIX"
LC_MESSAGES="POSIX"
LC_PAPER="POSIX"
LC_NAME="POSIX"
LC_ADDRESS="POSIX"
LC_TELEPHONE="POSIX"
LC_MEASUREMENT="POSIX"
LC_IDENTIFICATION="POSIX"
LC_ALL=

dpkg-reconfigure locales sur “none”.

locale -a
C
C.UTF-8
POSIX
fr_FR.utf8
~# env
COMP_WORDBREAKS= 
"'><;|&(:
TERM=xterm
SHELL=/bin/bash
SSH_TTY=/dev/pts/1
USER=root
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
PWD=/root
SHLVL=1
HOME=/root
LOGNAME=root
SSH_CONNECTION=192.168.1.1 40186 192.168.1.201 22
_=/usr/bin/env

w3m : Accès aux liens extérieurs de l'HTML ?

Est-ce que w3m accède aux URLs ?

On pourrait ptet remplacer par 'html2text', ou au pire 'tidy'

gpg

1er soucis, est-il sage de répliquer son répertoire .gnupg sur plusieurs machines ? Par commodité, je l'ai répliqué pour le compte utilisateur qui utilise mutt.

Après copie de mes fichiers issus de .gnupg, le déchiffrement des messages s'effectue bien au sein de mutt.

Tentative d'envoi d'email chiffré à une personne : sa clé est expirée. Je n'ai peut-être pas la bonne.

Le message est signé, alors je recherche (avec –recv-keys) la clé sur un serveur gpg public.

La clé 10*4 fait caractères hexadécimaux. Il en extrait les 8 derniers (2*4) pour effectuer la recherche.

gpg: demande de la clef E??????9 sur le serveur hkp keys.gnupg.net
?: keys.gnupg.net: Host not found
gpgkeys: HTTP fetch error 7: couldn't connect: Connection refused
gpg: aucune donnée OpenPGP valable n'a été trouvée.
gpg:       Quantité totale traitée : 0

Le problème correspond à celui-ci : https://bugs.launchpad.net/ubuntu/+source/gnupg/+bug/1044156

Installer gnupg-curl ne résoud rien. Ma version de gnupg est: 1.4.18-7+deb amd64

La résolution des DNS fonctionne :

$ dig keys.gnupg.net +short
pool.sks-keyservers.net.
95.130.11.215
138.201.135.108
94.142.242.225
5.45.108.219
130.206.1.111
144.76.26.250
204.61.209.238
161.53.2.209
193.224.163.43
131.175.15.4

Je n'ai pas ce problème sur ma machine sous Debian Testing, qui n'a d'ailleurs pas de paquet gnupg-curl dans ses dépots.

Contourner le problème

Rechercher la clé sur la machine sous Debian Testing, puis l'exporter.

gpg --export KEYID > zob.key

Générer et gérer une clé GPG ECC / curve25519

fdm

Gestion de boites mail collectives

FDM et la gestion des boites email utilisées collectivement est problématique.

Le serveur IMAP dispose d'un flag 'seen'. Si un autre client mail vérifie la boite, ce flag sera positionné, et notre fdm n'a aucune chance de rappatrier l'email.

Il y a peut-etre une façon alternative d'éviter les doublons dans les emails…

Un peu tiré par les cheveux, mais on pourrait faire des copies de la boite email d'origine. Les personnes consulteraient ensuite les copies. Le problème, c'est que les états des emails (répondus) ainsi que le répertoire sent, et les emails supprimés, ne seraient pas mis en commun.

Tiré par les cheveux aussi, on pourrait synchroniser les boites avec syncthing.

Dans le TODO de FDM on lit:

option to relax group ownership checks to permit secondary groups,
for shared mailboxes

Je comprends pas bien, je ne sais pas si ces histoires de droits peuvent aider.

Et enfin, illumination : j'abandonne mon idée de les rappatrier localement, et j'utilise mutt pour consulter les emails distants. Je peux toujours utiliser fdm comme filtre pour conserver une inbox propre, et rebalancer les messages dans les bons répertoires distants.

Autre piste de solution suggérée par fser : mettre en place une mailing-list à la place de la boite email.

Réparer la date des emails

Je m'y suis ptet mal pris, mais lors de manipulations sur une boite IMAP distante, la date du mail a été changée à l'heure courante.

Donc des emails datant de plusieurs mois/années se sont retrouvées listées dans le webmail avec la date d'aujourd'hui.

C'est un problème que fdm peut créer, et résoudre !

Au début, je pensais que la date était extirpée des entêtes. En fait, la date est issue de la date de dernière modification dans le système de fichiers.

Théoriquement donc, on peut retrouver la date dans les headers… et la réajuster en faisant un “touch” sur les fichiers d'email.

Malheureusement, la date est écrasée dès lors que l'on recopie le message vers la boite IMAP distante. Je n'ai pas trouvé de paramètre pour effectuer une copie tout en préservant la date du fichier. Cela sans doute dû au fait qu'un fichier est nouvellement créé sur le serveur qui réceptionne. Bizarre quand même.

Ca veut tout simplement dire qu'on ne peut pas réaliser des opérations d'archivage sur des boites IMAP distantes avec fdm.

msmtp

J'ai plusieurs SMTP sortants avec msmtprc.

Si j'utilise ceux de Gmail, bah ça marche évidemment…

Si j'utilise celui de Free, non authentifié, depuis un réseau Free : ça marche

Si j'utilise euuchépuquoi, ça marche pas.

Content-Description: Delivery report
Content-Type: message/delivery-status

Reporting-MTA: dns; mplserv.mply
X-Postfix-Queue-ID: 813A320A99
X-Postfix-Sender: rfc822; caca****@tuxfamily.org
Arrival-Date: Thu,  2 Mar 2017 16:23:59 +0100 (CET)

Final-Recipient: rfc822; d********@gmail.com
Original-Recipient: rfc822;d********@@gmail.com
Action: failed
Status: 5.7.1
Remote-MTA: dns; gmail-smtp-in.l.google.com
Diagnostic-Code: smtp; 550-5.7.1 [2a01:e35:8be8:e4e0:74fd:adff:fe50:2209] Our
    system has detected that 550-5.7.1 this message does not meet IPv6 sending
    guidelines regarding PTR 550-5.7.1 records and authentication. Please
    review 550-5.7.1  https://support.google.com/mail/?p=IPv6AuthError for more
    information 550 5.7.1 . k19si26418143wmi.125 - gsmtp

postfix

Là… je ne sais plus pourquoi j'ai mis Postfix. En concurrence avec msmtp. Msmtp rebalance vers postfix ?

Installé postfix. Choix de configuration: “site internet”, pour cacatoes.homenet.org.

L'envoi d'emails réussit ! Et je peux indiquer n'importe quoi comme adresse From.

Je ne me sert de postfix que pour l'envoi.

Ensuite, voir comment on configure SPF et DKIM.

Pour SPF, j'ai un problème lors de l'ajout de ce champ auprès du service DNS afraid.org. En investigation…

TXT @ "v=spf1 a include:_spf.mauvaispourlesyeux.tk ~all"

ou

"v=spf1 a include:_spf.mauvaispourlesyeux.tk ~all"

Une page pour tester si nos champs SPF sont bien ajustés : http://spf.myisp.ch/ Je me rend alors compte que c'est une erreur “d'inclure le champ SPF de mply”. Pour le DNS de cacatoes.homenet.org, je me contente donc de :

v=spf1 a -all

Tester l'envoi d'emails avec SPF : http://www.appmaildev.com/fr/spf/

Baarf, c'est pas encore ça. Quand le mail contient un From: mply.tk, c'est le champ TXT de mply.tk qu'il teste, et non pas celui d'homenet. Donc sur mply.tk, on doit effectivement renvoyer vers le domaine cacatoes.homenet.org.

bogofilter

Voir comment interfacer ça avec fdm et mutt.

La page de thuban donne déjà une réponse simple. Attention: l'entête bogofilter a dû changer, il faut mettre “Spam” au lieu de “Yes” dans les matches.

Le truc que je comprend pas, c'est pourquoi avec mutt il me marque comme “à supprimer” les emails que je classe comme Ham. C'est à cause du \nd en bout de ligne, on peut laisser \n (sinon il demande de valider la commande).

Fichier de config de bogofilter

P'tit prob : comment créer le fichier de config initial, quoi mettre dedans ?

/usr/share/doc fournit un example, qui est le même que /etc/bogofilter.cf

Apparemment, y'a rien de sensationnel à configurer dedans, hormis le chemin de stockage de la “wordlist”.

Voir aussi :

article/linux/mplx/emails.txt · Dernière modification: 2018/09/28 17:32 par fab