• Lien vers mes notes pour cet article (en anglais (???)): PDF

Qui n'a jamais rêvé de lire ses emails en ligne de commande et de recevoir tout le courrier adressé au domaine dans une seule boîte?

Je suis sûr qu'il y a au moins un gèque au fond de la salle qui a toujours rêvé d'avoir une infinité d'adresses jetables, ce qui est également l'objet de cet article: on veut pouvoir envoyer depuis n'importe quelle adresse, recevoir sur n'importe quelle adresse, et éventuellement bloquer des adresses de réception une fois qu'elles sont trop polluées.

On vous demande une adresse email pour enregistrer votre CONTRAT DE CONFIANCE pour la centrifugeuse à carottes que vous venez d'acheter?

- Ouioui vous pouvez utiliser je-vomis-sur-votre-service-client@dkvz.eu

A ce propos je vais rajouter une adresse email en clair sur ma page de contact pour voir si des robots-spammeurs viennent visiter mon site. Tout visiteur est le bienvenu. OK je suis désespéré.

Ce don't cet article ne traite pas: l'antispam. Je passe par un service antispam externe. Je vous laisse faire vos recherches à ce propos. Comme d'habitude, j'essaye de limiter au maximum l'empreinte mémoire et le nombre de process impliqués sur mon serveur à €4 par mois.

Mise en situation

Mon setup:

• Une VM (Veurtchual Mechine) ULTRA CHEAPOS avec Debian 8 Stable
• Postfix, version Debian Stable donc d'il y a 15 ans (2.11)
• Service antispam externe

Le fait que la VM soit ultra cheapos est un peu au centre du cas d'étude, je n'ai pas l'intention d'utiliser Mutt juste pour la classe et le feeling années 80, je souhaite utiliser Mutt pour éviter d'installer un serveur POP ou IMAP.

Le MTA (MAIL TRANSPORT AGENT) par défaut sur Debian est en fait Exim. Mais je ne sais pas pourquoi je l'ai toujours remplacé immédiatement par Postfix.

Quoi qu'il en soit le monde des MTA sur les systèmes Linux est assez limité. Que je sache il n'y a que Exim, Postfix, Sendmail (considéré comme le diable en personne, l'équivalent du BIND des années 80 pour les emails) et Qmail.

Ils sont tous un peu louches à configurer. Par ex. Qmail se configure en ajoutant des fichiers qui portent le nom d'un paramêtre de configuration et en écrivant la valeur dans le fichier. Je ne connais aucun autre programme qui fonctionne de la sorte. XML? YAML? Une vieille syntaxe .ini? Les développeurs de MTA n'utilisent pas ces trucs trop mainstream. Postfix lui-même est divisé en une chiée de process différents qui font chacun quelque chose d'unique (à la UNIX je suppose) L'email c'est un truc de sauvage okay?

Première chose à faire donc:

apt-get install postfix

Dans mon cas mon serveur ne doit pas être accédé par des serveurs SMTP externes à l'exception du service antispam que j'utilise et qui me forward mes emails sur le port que je veux.

Je peux dès lors bloquer l'accès à mon port SMTP à tout ce qui n'est pas lié au système antispam. Dans le cas d'une installation avec antispam sur le serveur lui-même, vous devez ouvrir le port TCP 25 pour accès depuis l'Internet.

Ouvrir un port à l'extérieur est toujours un vague risque dû aux tentatives intempestives d'envois ou de connexions (porte d'entrée possible pour une attaque de déni de service).

Configuration de Postfix

Par défaut Postfix crache les emails dans un mono-fichier dans /var/mail/<NOM_UTILISATEUR>.

Ce plan mono-fichier est une des pires idées au monde. Pour modifier ça, nous allons éditer le fichier de configuration principal de Posftix qui est /etc/postfix/main.cf.

Ajouter ces deux options (je conseille davantage le milieu du fichier que la fin (???)):

home_mailbox = Maildir/
mailbox_command =

Vérifiez qu'il n'y a pas déjà mailbox_command quelque part dans le fichier. Par défaut cet élément de configuration est déjà présent. Retirez-le ou remplacez la valeur par le vide comme ci-dessus.

Recharger Postfix:

/etc/init.d/postfix reload

Configuration du domaine

Je n'ai pas l'intention de donner tout un cours sur Internet et les emails, mais vous allez devoir ajouter des enregistrements MX à votre domaine/sous-domaine ou les modifier de sorte que les emails arrivent sur votre serveur.

Par défaut Postfix va accepter la livraison d'email pour les utilisateurs locaux du système. Par exemple, si vous avez un utilisateur qui s'appelle "francky" et que votre machine s'appelle "croutte", vous pouvez demander à Postfix, depuis l'extérieur, de livrer un email à francky@croutte, et ça va fonctionner même si c'est totalement inutile. C'est comme ça qu'on "chattait" dans les années 80.

Comme j'ai l'intention d'utiliser Mutt avec un utilisateur non-root, je vais faire en sorte que tous les emails arrivent chez cet utilisateur sytème. J'ai choisi de l'appeler mailuser. Créez votre user:

adduser mailuser

Vous pouvez le laisser sans mot de passe si vous voulez éviter qu'il soit possible de se connecter en SSH avec cet utilisateur.

Pour pouvoir accepter les emails de notre (ou nos) domaine(s), on va créer un fichier /etc/postfix/virtual et ajouter ça dedans:

@dkvz.eu mailuser

Remplacez "mailuser" par le nom de l'utilisateur système que vous souhaitez utiliser pour lire vos emails.

Une fois le fichier enregistré, il existe une commande pour générer un fichier .db (format BerkleyDB il me semble) qui puisse être utilisé par Postfix:

postmap /etc/postfix/virtual

Vous devrez relancer le même postmap à chaque modification du fichier.

Nous pouvons maintenant éditer à nouveau /etc/postfix/main.cf et ajouter:

virtual_alias_maps = hash:/etc/postfix/virtual

Il faut faire un /etc/init.d/postfix reload pour que ça soit pris en compte.

Autorisations

Il y a pas mal de chances que même avec le domaine configuré dans virtual_alias_map, les emails destinés à ce domaine soient refusés en réception par Postfix.

Il y a plusieurs clauses de configuration liées aux autorisations, et je n'y ai jamais rien compris. Sur ma Debian c'est celle-ci:

smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination

Pour que la réception soit autorisée avec cette ligne smtpd_relay_restrictions, il faut ajouter votre domaine à la ligne "mydestination" (vous pouvez ajouter plusieurs domaines séparés par des virgules):

mydestination = monserveur.croutte.net, localhost, dkvz.eu

Je conseille de laisser localhost, certains programmes envoient des notifications à root@localhost (par exemple.)

Pas oublier de reload Postfix à chaque modification.

Consulter ses emails

A ce stade, si votre domaine est configuré correctement au niveau DNS, les emails envoyés à votre domaine devraient apparaître dans votre répertoire Maildir de /home/<VOTRE_UTILISATEUR_MAIL>. Si ça ne fonctionne pas, je vous invite à consulter /var/log/mail.log ou essayer d'envoyer un email directement sur le serveur en telnet (il faut parler SMTP par contre mais je ne doute pas de vos capacités).

A ce stade il y a déjà moyen de lire vos emails comme un gros, large et veineux guerrier de la ligne de commande en lisant les fichiers dans Maildir/new avec cat ou nano, vim etc.

Sinon les outil email en ligne de commande les plus connus (ouais en fait je pense qu'il n'y en a que deux) sont:

• Alpine
• Mutt

Ils sont tous les deux moches, mais je préfères Mutt qui "a l'air" mieux maintenu. C'est la première impression qui compte vous savez? Par contre il peut être assez sauvage à configurer mais ça vous ne le savez pas avant d'avoir accepté d'emménager avec.

Installation

Installer Mutt:

apt-get install mutt

Sans aucune configuration particulière, Mutt peut déjà ouvrir une mailbox au format Maildir de cette manière:

mutt -f /home/<USER>/Maildir

Où est votre utilisateur email configuré dans la section précédente.

Mutt devrait déjà être en mesure d'envoyer des emails à ce stade, mais nous avons de la configuration velue à faire avant de poursuivre.

Configurer Mutt

Le paquet Debian place une configuration générale dans /etc/Muttrc. Une fois ces préférences chargées, mutt chercher les préférences utilisateur qui sont soit:

• Dans un fichier .muttrc dans le répertoire utilisateur
• Dans un fichier muttrc (sans point quoi) dans /home/<USER>/.mutt/muttrc

Je conseille la second option pour des raisons semi-obscures qui ne seront pas expliquée plus tard.

A ce stade on pourrait configurer root pour la lecture des emails mais par soucis de cohérence psychomaniaque j'utilise mon utilisateur mail. Je fais un su mailuser d'abord, chaque fois que je veux lire mais emails. C'est à dire une fois par mois.

Sur Debian et probablement les autres GNU/Linux basés sur Debian (Ubuntu, Mint), mutt va utiliser votre éditeur de texte en ligne de commande par défaut courant pour écrire des emails (mutt n'inclut pas d'éditeur).

Pour des raisons que je n'explique pas, le paquet mutt installe le moins populaire de tous les éditeurs de texte au monde, "joe", qui est le nom de l'auteur je pense. C'est un peu comme si j'écrivais un serveur HTTP et que je l'appelais JEAN-PHILIBERT. Pour aller jusqu'au bout de la blague l'éditeur joe est aussi enregistré comme éditeur par défaut.

Personnellement j'utilise Vim, mais Nano est simple et efficace et tout aussi recommandable. Pour changer d'éditeur par défaut sur un système Debian:

update-alternatives --config editor

Ensuite choisissez une des alternatives proposées.

Fichier de config perso épuré

Pour aller directement à l'essentiel, voici mon fichier de config:

set mbox_type = Maildir
set folder = ~/Maildir/
set spoolfile = +/
set realname = "<VOTRE_NOM>"
set from = "<ADRESSE_MAIL_PAR_DEFAUT>"
set use_envelope_from = yes
set edit_headers = yes                                   # Will allow us to change the from address from Mutt
set record = +/sent/
set sort = threads
auto_view text/html                                      # view html automatically
alternative_order text/plain text/enriched text/html     # save html for last

Je suis un disciple de la philosophie de ne pas inclure des options que-personne-sait-ce-que-ça-fait.

Il s'agit de remplacer <ADRESSE_MAIL_PAR_DEFAUT> par l'adresse email d'expédition que vous voulez que mutt utilise par défaut (vous pourrez changer facilement l'adresse d'expédition dans l'éditeur). Idem, remplacez <VOTRE_NOM> par le nom qui apparaîtra par défaut sur l'enveloppe.

La partie qui spécific edit_headers = yes va nous permettre de modifier n'importe quel en-tête avant d'envoyer un email, c'est de cette manière que l'on pourra changer facilement l'adresse d'expédition et le nom sur l'enveloppe.

Avec cette config il suffit d'invoquer mutt sans arguments pour ouvrir correctement votre boîte mail, puisque les répertoires ont été spécifiés dans le fichier de config.

Au niveau des alternatives de contenu présentes dans les emails que l'on vous envoie (parce que ce que vous envoyez est toujours juste en texte brut dégeulasse) mutt essayera toujours de charger le texte pur si cette alternative existe. Si votre correspondant utilise le Outlook fourni avec Windows 98 peut-être que vous n'aurez que l'email en HTML. Il est possible de fournir à mutt des moyens d'afficher des fichiers non-texte en lançant un programme externe.

Par exemple si vous utilisez mutt sur une box qui a également une interface graphique (ce qui est une très drôle d'idée mais je ne juge pas (si en fait je juge à mort)) vous pouvez spécifier que les types MIME d'image peuvent être ouverts avec un visualisateur d'image local, ou encore les fichiers HTML par Chrome ou Firefox. Nous comme on a pas d'interface graphique on va devoir utiliser un navigateur en ligne de commande.

Je suis sûr que vous vous êtes déjà demandés "lol qui utilise un navigateur en ligne de commande sans souris, sans images et tout" - MOI.

De toutes manières les parties alternative en text brut sont souvent mal faites car traduites de l'HTML à l'arrache.

Personnellement j'utilise w3m:

apt-get install w3m

Pour opérer la correspondance entre un type mime et un programme à lancer, il s'agit de créer un fichier dans le répertoire .mutt de notre utilisateur, c'est-à-dire aux côtés du fichier muttrc créé précédemment.

Créer ce fichier et nommez le "mailcap". C'est parce que ça capture euh... Les mails. Truc du genre. Le contenu du fichier:

text/html; w3m -I %{charset} -T text/html; copiousoutput;

Si vous voulez tester tout ça, ouvrez un email avec plusieurs alternatives dans mutt, tapez "v", sélectionnez l'alternative HTML (à supposer qu'il en ait une), w3c devrait s'ouvrir. Quitter w3c revient à mutt. Cette technique est très pratique pour visualiser correctement des tableaux qui sont très mal rendus dans l'alternative texte, en général (tout le temps).

Problèmes de charset

Je dois dire que ça m'étonne mais je n'ai eu aucun problème de charset et de caractères foireux qui ne s'affichent pas comme il faut, avec une connexion via SSH (client Putty) et toutes sortes d'encodage d'email differents. Pluôt chouette quoi.

Je ne l'ai pas testé mais il y a des chances que si vous avez des soucis d'encodage, ajouter ceci dans votre muttrc puisse aider:

set charset="utf-8" 
set locale="fr_FR.UTF-8"

Utilisation avancée

Mutt sait faire bien plus de choses, comme lire des boîtes POP ou IMAP. Si vous voulez pousser le vice de mutt tellement loin qu'il vous ressort par la bouche, il y a des tutos pour lire sa boîte Gmail dans mutt (en IMAP, simplement).

Toutes les couleurs peuvent être modifiées dans la config, ainsi que tout un tas d'autres trucs qui sortent du cadre de cet article et de ma volonté de passer des heures à tout tester.

Je vous livre tout de même quelques astuces en passant.

Forwarder

Forwarder n'est pas très clair dans mutt. Presser "f" ne va jamais forwarder les attachements par exemple. De nos jour on veut générallement forwarder les attachements avec. Pour cela il s'agit d'effectuer un "re-send" (Esc + E) et de modifier les en-têtes.

Rafraîchir la boite de réception

Par défaut mutt ne parcours la boite mail que si on interagit avec l'interface. Moi ça me convient très bien. Si vous voulez un refresh automatique, je conseille de faire des recherches sur la directive de configuration timeout.

Classer les emails

Par défaut le plus récent apparaît en dernier dans mutt. Ce qui est l'inverse de ce que fait le monde entier où on classe presque toujours par date décroissante (modifiable en cliquant sur une colonne de l'interface).

Des filtres textuels d'affichage peuvent être appliqués. Encore une fois ça sort du cadre de mon cas d'utilisation, j'efface les emails lus de toutes manière. Je dirai juste que quelque chose de simple en apparence comme classer les emails par date avec le plus récent d'abord est étrangement compliqué à configurer. Et je suis mega paresseux.

Quotas et protection de l'espace disque

Laisser certains programmes sans quotas d'utilisation de disque à ne pas dépasser peut être dangereux. Quelqu'un pourrait avoir envie de vous mailbomber pour une raison ou une autre, et de vous mailbomber la narration complète de la Bible en mp3, 150 000 fois. Ce qui va ruiner votre serveur en utilisant tout l'espace disque.

Comme j'aime bien aller au fond des choses (enfin, de certaines choses), je vais vous livrer une technique pour appliquer un quota, et s'assurer que Postfix soit en mesure de prévenir vos correspondants que votre boite est pleine.

Il y a plusieurs solutions, on pourrait créer un fichier avec dd qui pourrait être monté comme un disque dur (il y a même moyen de le faire en thin provisioning (enfin il paraît)) et la taille limitée de ce "disque dur" virtuel devrait suffire comme protection. Je ne l'ai pas testé mais normalement si Postfix ne peut plus écrire dans la mailbox il renvoie une erreur 500 à l'expéditeur, l'informant donc que votre boite est pleine.

En utilisant "quota"

La solution que j'ai choisie utilise quota (oui ça s'appelle comme ça), qui est bien connu des personnes qui gèrent des serveurs mutualisés et ce genre de choses. C'est en effet dangereux de mutualiser quelque chose sans quota.

D'abord, installer le paquet:

apt-get install quota

Il est maintenant nécessaire d'éditer /etc/fstab. Dans mon cas je n'ai qu'un seul volume qui est le point de montage de "/". Ce serait mieux d'avoir une partition /home séparée et d'appliquer les modifications dessus. Je vais devoir les appliquer sur la partition racine. Il faut y ajouter ces options:

usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0

Il faut remonter la partition pour que ça s'applique. Toujours dans le cas de "/", on peut utiliser cette commande:

mount -o remount /

Me demandez pas pourquoi mais il faut absolument créer une DB d'usage quota machin bidule:

quotacheck -avugm

Ce qui crée deux fichiers à la racine des volumes montés sur lesquels les quotas sont appliqués (configuré dans fstab). Dans mon cas il crée ces deux fichiers à la racine du système ("/").

Il faut encore activer les quotas:

quotaon -avug

Il est désormais possible d'ajouter des quotas pour les utilisateurs avec la commande:

edquota 

Où est le nom de l'utilisateur à qui vous souhaitez appliquer un quota. Dans mon cas c'est "mailuser".

La commande devrait ouvrir votre éditeur de texte par défaut et un fichier avec des colonnes. Pour faire simple et rapide, vous pouvez uniquement vous attarder sur la colonne "hard" qui est la limite effective après laquelle l'utilisateur ne peut plus écrire sur le volume protégé par le quota. La partie amusante étant qu'au lieu d'être en bytes ou je sais pas quoi, la taille est en blocks. QUE DE Fuq c'est un BLOC?

Plutôt que d'essayer de comprendre j'ai Googlé "gigabyte to block calculator" et utilisé ce truc: Calculatrice de BLOCS

La première colonne du fichier indique l'usage actuel (en blocs bien entendu n'est-ce pas).

Sur une Debian avec ce setup, les quotas seront désactivés au prochain démarrage. Ce qui n'est pas très convivial. Pour y remédier nous allons devoir enregistrer le service, à la mode systemd:

systemctl enable quota.service

Quand le quota est dépassé pour un utilisateur et que Postfix doit lui transmettre un message, la livraison échoue et l'expéditeur est informé qu'il s'agit d'un dépassement de quota:

May 31 16:22:43 deb8 postfix/local[1885]: 06CF120055C: to=, relay=local, delay=9, delays=8.9/0/0/0.1, dsn=5.2.2, status=bounced (maildir delivery failed: error writing message: Disk quota exceeded)

En tant que root, cette commande fournit un rapport rapide sur l'usage des quotas des utilisateurs:

repquota -a

Et l'option mailbox_size_limit de Postfix?

Dans le fichier de config. main.cf de Postfix on trouve générallement ceci:

mailbox_size_limit = 0

L'option semble indiquer qu'elle pourrait être utilisée pour limiter la taille des boites mail. En fait non. Cette directive semble empêcher le process "local" (la partie livraison de Postfix) d'écrire des fichiers plus grands que cette limite (en bytes).

La seule utilité que je vois pour cette option, et c'est bien parce que j'ai poussé très fort et suis devenu tout rouge, c'est si on utilise également message_size_limit (taille max des emails envoyés par Postfix) et qu'il est immense parce qu'on veut envoyer des fichiers gigantesques, mais par contre limiter la taille de ce qu'on reçoit.

Ouais on s'en fout.

Soft additionnel type "policy"

Postfix peut être configuré pour utiliser des processus externes pour décider de la destinée d'un email, par exemple en contactant un service en TCP (avec une réponse qui devra être dans un format bien précis).

Ce processus externe peut avoir son propre mécanisme de vérification de quota. Il existe plusieurs projets de systèmes "policy" pour Postfix, peut-être qu'il y en a un quelque part qui sait gérer les quotas d'une manière ou d'une autre. Personnellement, je préfère utiliser quota donc ceci sort du cadre de l'article.

Utiliser une partition séparée

Je crois que j'en ai déjà parlé dans l'intro mais l'utilisation d'une partition séparée pour y enregistrer les emails vous protège naturellement puisque vous ne pourrez pas dépasser la taille prévue tout en laissant la partition système bien tranquille de son côté.

Vous pourriez même pousser plus loin en utilisant LVM, ce qui vous permettra de réaliser des snapshots, étendre le volume de manière, etc.

C'est également possible de monter un disque virtuel créé avec dd, bien que cette méthode va réserver tout l'espace disque de votre disque virtuel à l'avance. Donc dans l'idée d'économie d'espace c'est pas top. Il semblerait qu'il soit possible de créer des volumes dd qui ne soient pas entièrement provisionnés à l'avance mais je n'ai pas testé. Pour ceux que ça intéresse (HAHAHA): https://wiki.archlinux.org/index.php/Sparse_file

Quoi qu'il en soit il s'agit probablement toujours d'une demi-solution parce que je ne pense pas qu'il soit possible de récupérer l'espace provisionné sur un tel disque virtuel. C'est-à-dire, si le disque était particulièrement rempli et que vous y effacez beaucoup de données, il devrait garder l'espace provisionné précédemment et donc rester dans l'état "particulièrement rempli" du point du vue du système de fichier qui hébèrge le disque virtuel.

Eviter d'être marqué comme SPAM

Peut-être que ça n'en a pas l'air, mais c'est la plus grosse part du gateau.

Personnellement je me suis "limité" à essayer de pouvoir envoyer des mails à des adresses Gmail. Ce qui est déjà pas mal. Je pense que Gmail est le plus strict, avec ses propres listes de réputation et son propre mécanisme obscur. Normalement, si ça passe sur Gmail, ça soit pouvoir passer chez les autres comme outlook.com.

Que je sache, Gmail va toujours vous marquer comme spam les emails qui partent de votre serveur perso. Je ne sais pas si c'est lié à la réputation de l'hébergeur chez qui est votre serveur, c'est possible qu'il y ait un lien. Les gros hébergeurs sont de toutes façons tout pourris au niveau "réputation IP" et vous ne pouvez rien y faire.

Voici un résumé de quelques expériences sur mon aventure de dé-spammage par Google.

Comprendre la raison

Spoiler: ON PEUT PAS

Vous devriez voir vos emails envoyés depuis votre serveur perso dans votre dossier spam de Gmail (qui n'est parfois même pas visible dans l'interface, il se peut qu'il faille déployer le menu de droite (PUT* CE SUBJONCTIF LES MECS)).

Si vous cliquez sur un des emails, il devrait apparaître une mention sur la raison pour laquelle cet email a été marqué. Dans mon cas:

Il semblerait donc que mes emails soient marqués parce qu'ils sont semblables à d'autres messages indésirables détectés par leurs filtres. Je pense qu'il s'impose de cliquer sur "Learn more". Ce qui vous amène sur cette page: Marquer des emails comme spam.

Il me semble avoir vu quelque part une liste de raisons de marquage et une vague explication associée, mais je ne parviens plus à retrouver cette information.

Il est important de noter qu'à ce moment, si vous marquez cet email comme "non spam", vous pourrez recevoir tous vos emails de votre serveur perso normalement, mais uniquement sur ce compte Gmail, ainsi que sur les comptes qui auraient ajouté votre adresse d'expédition dans leurs carnets d'adresse. Je ne sais pas si c'est le comportement normal pour tous les serveurs persos, à ce stade j'avais en fait déjà mis en place un enregistrement SPF conforme (expliqué plus bas dans cet article).

Par conséquent ne marquez surtout pas vos emails comme non-spam immédiatement ou vous ne pourrez plus tester la réception sans créer un nouveau compte Gmail.

Je vous livre tout de suite l'interprétation que je fais de la raison du marquage par Google et que j'ai déterminé empiriquement en ayant recours à un bon nombre de mesures expliquées dans cette section de l'article: votre serveur d'expédition est encore inconnu et n'a pas envoyé assez d'emails non marqués comme spam à au moins une boite Gmail. C'est tout. En fait c'est extrêmement simple.

Après je ne dis pas qu'il n'est pas essentiel d'ajouter quelques mesures de vérification comme je le fais ci-après, mais vu qu'au final ce qui m'a débloqué ma situation c'est juste coder un robot qui envoie des centaines de mail par jour à ma boite Gmail, je me pose des questions.

Enregistrement SPF

Le SPF est un enregistrement DNS de type texte à ajouter à votre domaine. Il mentionne les adresses IP autorisées à envoyer du courrier pour votre domaine et donne une indication sur ce qui devrait être fait si un envoi est reçu d'une autre adresse IP. Le SPF permet aussi d'autres choses mais on va se limiter à ça pour l'instant.

Je recommande l'utilisation d'un outil de génération comme celui-ci: www.spfwizard.net

Moi j'avais commencé avec ceci (formatté comme si trouvé dans un fichier .dns):

dkvz.eu.  IN TXT "v=spf1 mx a ip4:51.255.166.120 ~all"

Ce qui autorise mon serveur à envoyer, avec la mention SoftFail, qui signifie qu'on est censé s'en battre un peu le beurre si un email est reçu d'une autre adresse. Mon espoir était que Google allait voir que j'envoie bien avec l'adresse IP mentionnée et être tout content. QUE NENNI VALERY, il s'en bat les gonades mais complètement.

Pour être certain que je me suis pas planté, je vérifie mon SPF avec cet outil: https://mxtoolbox.com/spf.aspx

Et c'est bien correct. De plus, Gmail le signale également. Il s'agit d'aller repêcher l'email envoyé dans vos spam sur Gmail (NB. Au fait il vous faut au moins un compte Gmail pour réaliser ces expériences), cliquer sur l'email ou la conversation et utilisé le menu attaché à cet email pour cliquer sur Show Original. Le résultat du check SPF apparaît dans les premières lignes.

A ce moment j'ai adapté mon SPF pour qu'il soit:

v=spf1 mx a ip4:51.255.166.120 -all

Ce qui revient juste à changer ~all en -all, indiquant qu'il est adéquat de formellement refuser tout email envoyé pour ce domaine depuis une adresse IP qui n'est pas présente dans le SPF. C'est le plus strict que je puisse faire.

C'est difficile de tester correctement à ce moment-ci parce que Google garde les SPF en cache pendant longtemps. Comme je suis hyper consciencieux et toussa j'ai attendu plusieurs jours pour retester avec mon nouvel enregsitrement SPF. Ils avaient toujours la mauvaise entrée en cache. J'ai trouvé une page obscure quelque part pour "clear le cache Google" dans laquelle j'ai entré mon domaine, ça a l'air d'avoir fonctionné dans les heures qui suivent. Je ne sais plus du tout où était cette page.

Quoi qu'il en soit, le résultat est que mes mails sont toujours dans les spam.

Conclusion: C'est difficile à dire si le SPF aide ou pas puisque le résultat est le même avec ou sans. Peut-être que ça va s'aggréger à d'autres choses que je vais rajouter, difficile à dire. Mais en tous cas, seul, ça n'aide pas.

DomainKeys

DomainKeys semble avoir été remplacé par un nouveau projet appelé DKIM (DomainKeys Identified Email).

C'est assez similaire au SPF sur le principe sauf qu'il faut se créer des paires de clés et mentionner la clé publique de vos SMTP au niveau DNS. C'est expliqué ici assez bien pour Debian:

How to Installl and Configure DKIM with Postfix on Debian Wheezy

Un autre:

Configure SPF and DKIM in Postfix on Debian 8

Ce truc me paraît bien trop compliqué, en plus je suis 89% certain que ça ne va servir à rien et il faut ajouter un processus résident en plus sur le serveur, ce que j'essaye d'éviter. Donc non. Je passe.

Pour info, le check DKIM est aussi mentionné dans "Show Original" sur Gmail (comme expliqué pour SPF plus haut), mais dans les en-têtes cette fois-ci.

Reverse DNS

Il devrait être possible de modifier l'entrée reverse-DNS (PTR) correspondant à votre adresse IP quelque part chez votre hébergeur (celui qui possède l'adresse IP). Votre adresse IP est censée correspondre soit à votre domaine email racine, soit en être un sous-domaine, ou les serveurs mail trouvent ça louche.

Tant qu'on y est, je conseille de bien vérifier que votre serveur s'identifie exactement comme son entrée PTR quand il dit EHLO à un autre serveur. En pratique, dans /etc/postfix/main.cf, faites en sorte que myhostname soit bien ce qui est aussi inscrit comme reverse DNS pour votre adresse IP.

Google met également les résolution reverse DNS en cache pendant longtemps.

Conclusion: Après avoir bien vérifié que Google avait la bonne entrée PTR pour mon serveur et pas le truc foireux initial, mes emails se retrouvent toujours dans les spam. A ce stade, j'ai SPF correct et strict + Reverse DNS.

DMARC

DMARC c'est ça: https://dmarc.org/

Si j'ai bien compris ce que j'ai lu sur ce site en 3 secondes un soir après deux Chouffes il faut DKIM + SPF pour utiliser DMARC, et j'ai bien l'intention de complètement nier DKIM. Je passe.

TLS

Les serveurs Postfix n'encryptent pas leurs communications SMTP vers l'extérieurs par défaut, alors que tous les gros providers mail (ainsi que Microsoft Exchange) le font.

Par conséquent si vous envoyez un email depuis un Postfix à une adresse Gmail, vous voyez un cadenas rouge ouvert à côté de "Me" quand vous visualisez les détails d'un email, avec la mention que votre serveur n'a pas encrypté le message. Je n'ai absolument aucune idée de si ça rentre en compte dans la classification comme spam, mais vu que c'est rouge et que le rouge ça fait peur (et surtout que je commence à être désespéré), je me dis, pourquoi pas essayer d'arranger ça?

La doc officielle Postfix explique sa raison de ne pas utiliser TLS par défaut:

NOTE: By turning on TLS support in Postfix, you not only get the ability to encrypt mail and to authenticate remote SMTP clients or servers. You also turn on hundreds of thousands of lines of OpenSSL library code. Assuming that OpenSSL is written as carefully as Wietse's own code, every 1000 lines introduce one additional bug into Postfix.

Je ne pense pas qu'il y ait de raison de faire preuve d'un niveau médicalement diagnostiqué de paranoïa, je n'ai jamais eu de problème avec l'utilisation de TLS sous Postfix en tant que client.

La manière de procéder dépend de votre version de Postfix parce que sinon c'est pas drôle. Sur une 2.3+ il s'agirait d'ajouter ces lignes dans /etc/postfix/main.cf (je ne l'ai pas testé):

smtpd_tls_security_level = may
smtp_tls_security_level = may

Si comme moi vous vous tapez les vieilles versions crouteuses qui sont sur Debian "stable", vous avez probablement une 2.1. La doc relative au 2.1 est ici et vous devez juste ajouter cette ligne dans main.cf (faut reload Postfix aussi évidemment):

smtp_use_tls=yes

Désormais si vous envoyez de votre serveur perso à Gmail, vous devriez voir ceci:

J'ajouterai que normalement TLS authentifie votre serveur aussi (enfin je pense) et que pour ça il lui faut un certificat valide. Ce qui ne doit pas être extrèmement compliqué à mettre en place avec letsencrypt.org. Mais moi je suis beaucoup trop feignasse pour ça, donc mon certificat est tout pourri. Néanmoins Gmail n'a pas l'air de se plaindre (l'encryption fonctionne c'est l'authentification qui est impossible).

La conclusion de mon ajout de TLS: Le cadenas ouvert rouge a disparu. Mais je suis toujours dans les spam. A ce stade j'ai SPF (strict) + Reverse DNS + TLS.

Mode désespoir

Puisque ça fonctionne toujours pas, voici quelques autres actions entreprises dans le but de ne pas être marqué spam par Google.

Postmaster Tools

J'ai vu quelqu'un sur un forum quelque part recommander d'enregistrer son domaine dans les Postmaster Tools de Google.

Une fois votre domaine validé, on arrive sur un genre de page expérimentale probablement réalisée par un stagiaire avec vos domaines enregistrés. Sur mes options de domaine je peux consulter des statistiques sur les emails entrants chez Google de mon domaine, ceux qui sont marqués comme spam etc. Sauf que je ne vois absolument rien du tout parce qu'il me dit "volume d'email insuffisant pour avoir des données".

Ce petit commentaire sera mine de rien important parce qu'il me mettra sur la piste de ce qui va vraiment résoudre mon problème.

Le user agent de Mutt

J'en arrive à me demander si ce n'est pas le contenu des emails que j'envoie? Ce serait étrange parce qu'il y a une autre raison de marquage comme spam bien précise pour le contenu, et ce n'est pas cette raison là qu'ils me donnent. Ouais je sais vraiment pas pourquoi j'ai essayé ça, le désespoir. J'ai tenté de forcer l'user agent de Mutt pour être comme Thunderbird, c'était sans effet.

Les listes de réputation

Google utilise ses propres listes de réputations (enfin c'est ce qu'ils disent). Sur le net il y a plusieurs outils de réputation et comme je le disais précédemment dans cet article, si vous êtes chez un gros hébergeur votre réputation "IP" est automatiquement à chier.

A ce point je me suis enregistré sur SenderScore pour voir leurs recommandations. A part me dire que DKIM ce serait cool, j'ai un bon score.

Idem avec www.mail-tester.com. Cet outil réceptionne un mail que vous lui envoyez, il suffit alors d'attendre un peu puis cliquer le bouton et vous avez votre rapport. Je ne sais plus tout ce que j'avais chipoté quand j'ai eu le mien:

Il est bien indiqué que je ne suis pas blacklisted, ce qui était ce qui m'importe le plus. Puis 7/10 c'est pas trop mal, moi j'étais content avec 7/10 en math. Puis ils disent eux-mêmes "Good stuff". Cool.

Envoyer PLUS de mails

C'est l'histoire de postmaster.google.com qui m'a fait réfléchir sur le volume d'email. Peut-être que Gmail n'a juste pas assez vu d'emails en provenance de mon serveur. Et que c'est juste ça. Ce serait vachement stupide comme raison, surtout vu la manière dont c'était présenté, mais qui sait?

Etape 1: Se rendre dans les spams sur son Gmail, et signaler que les emails de votre serveur ne sont pas des spams. Envoyer à nouveau un email depuis Mutt pour bien vérifier qu'il est reçu dans votre boite de réception Gmail et pas dans les spams. Si vous êtes toujours dans les spams je ne peux pas vous aider.

Etape 2: Composer le script de l'année:

#!/bin/sh

free -m | mutt -s "Test from mutt" mon-adresse-gmail@gmail.com

Puis je l'ai mis dans mon crontab pour exécution toutes les 5 minutes. Oui j'envoie l'état de la mémoire du serveur dans l'idée d'avoir du contenu qui varie pour mes emails de masse. Je n'ai aucune idée de si cet aspect est important ou non.

Pour ne pas polluer ma boite j'ai ajouté une règle qui déplace tous ces emails dans un dossier particulier. Gmail les classe en une seule conversation, ce qui est bien pratique n'est-ce pas.

Après quelques jours, je me crée deux autres adresses Gmail de test, et je leur envoie des emails de mon serveur perso. Devinez quoi? Je ne suis plus dans les spams.

Conclusion

J'ai déjà écrit la conclusion dans l'intro. En fait il suffit de dire à Gmail que c'est pas du spam sur un compte, puis envoyer tout plein d'emails avec un robot à ce même compte. Attendre. Après quelques jours c'est bon. J'ignore s'il est absolument nécessaire de varier le contenu des emails de masse. Je conseille de le faire de toutes façons.

Bloquer des adresses de réception

Avec ou sans filtre antispam de votre côté, vous allez inévitablement avoir des adresses complètement polluées par des milliard de newsletters sur le Slip Français ou des vacances en Afghanistan. Le but du catch-all étant d'avoir une infinité d'adresses jetables, ce serait pas mal d'avoir un moyen d'effectivement jeter des adresses.

Vous pouvez bloquer des adresses de réceptions en utilisant les recipient restrictions de Postfix, que l'on pourrait configurer de sorte à autoriser toute adresse de destination sauf celles mentionnées, ou le contraire. Dans mon cas je veux implémenter la première possibilité: tout autoriser sauf ce que je mentionne.

Première étape: créer le fichier /etc/postfix/recipient_access et l'éditer.

La syntaxe est expliquée par cet exemple:

janedoe@acme.local  REJECT
luc@acme.com        REJECT

A noter que si vous souhaitiez utiliser la règle inverse, c'est à dire tout rejeter sauf quelques adresses de destination, il s'agit d'utiliser OK au lieu de REJECT.

Une fois les adresses de réception condamnées inscrites dans le fichier, l'enregistrer et lancer cette commande (ici supposant que je suis dans le répertoire où est recipient_access):

postmap recipient_access

Il suffit maintenant d'ajouter une ligne à /etc/postfix/main.cf (tout à la fin, et si vous n'avez pas déjà cette directive présente):

smtpd_recipient_restrictions = check_recipient_access hash:/etc/postfix/recipient_access, permit

Pour le scénario inverse, c'est à dire tout refuser sauf pour les adresses mentionnées dans recipient_access, cette ligne devrait fonctionner:

smtpd_recipient_restrictions = check_recipient_access hash:/etc/postfix/recipient_access,  reject_unauth_destinations

Il faut chaque fois faire un reload de Postfix pour appliquer les changements. Quand vous ajoutez des adresses n'oubliez pas de faire un postmap du fichier ainsi qu'un reload de Postfix à chaque fois pour prendre la modification en compte.