> DIO/ Système et réseau/ redirection mel

Redirection des Méls

Le CNRS n'autorise pas la redirection des mél CNRS vers une boite mél extérieure. L'Observatoire de Paris en 2023 la tolère.

Bonne ou mauvaise idée ? Qui a tort ? Qui a raison ? Pas si simple...

Dans ce document le nom de domaine « observatoiredeparis.psl.eu » est remplacé par sa version courte « obspm.fr ». Au vu du nombre de répétition de celui-ci, et l'âge légal de départ à la retraite étant repoussé de 2 ans, je préfère économiser mes articulations.

Risque Cloud-Act

L'acte paraît anodin, mais rediriger l'ensemble de son courrier vers l'extérieur, et à plus forte raison vers des multinationales telles que Google, est d'une part interdit et d'autre part c'est leur offrir vos données sur un plateau. Les données déposées sur un serveur américain tel que gmail, dropbox... leurs appartiennent car relevant du CLOUD Act.

Pour caricaturer, si c'est gratuit c'est toi le produit !

Un exemple est plus parlant qu'un long discours : un collègue de l'établissement avec qui vous collaborez vous envoie la dernière version du brevet sur lequel vous travaillez ensemble depuis 7 ans. Si vous avez une redirection gmail, alors votre brevet finit sur les serveurs de Google. Google devient alors propriétaire de vos données et peut automatiser le dépôt de brevet à votre place et pour son propre compte.

L'Observatoire et le CNRS vous fournissent une adresse mél, utilisez-la directement sans la rediriger. La redirection de la boite Observatoire est toutefois tolérée vers les établissements de la fonction publique. Il vous est donc possible de rediriger obspm.fr --> cnrs.fr, mais attention le quota du CNRS est limité à 2 Go, à l'Observatoire nous avons 20 Go !

Voyons maintenant les autres problèmes que peuvent poser ces redirections automatiques de courrier électronique.

Problème du Spam

Tout spam qui arrive sur votre boite mél Observatoire, transitera à l'Observatoire et sera redirigé vers l'extérieur. L'Observatoire va donc renvoyer ce spam et devenir émetteur de spam à l'insu de son plein gré !

En agissant ainsi, vous salissez la réputation de l'Observatoire, votre employeur. Si la réputation baisse trop, certaines structures refuseront la réception des méls, mais pas uniquement vos méls, ils refuseront l'ensemble des méls émis par notre serveur donc également ceux de vos collègues.

Par conséquent, plus vous serez nombreux à rediriger les méls, plus la réputation de l'établissement sera ternie.

Problème de réception

Pour limiter le spam, de plus en plus de structures détectent la cohérence des noms de domaine (ex. obspm.fr) et bloquent le mél si une anomalie est détectée.

Un nouvel exemple parlant sur une réception de mél : Monsieur.chercheur@observatoire.nice vous envoie un mél sur mon.mel@obspm.fr que vous redirigez sur plus.pratique@gmail.com

  1. Au niveau de mon.mel@obspm.fr, pour chaque mél reçu nous allons vérifier le domaine émetteur, en l'occurrence, le mél arrive depuis "observatoire.nice", l'ip correspond bien, tout est ok !
  2. Réception acceptée. Le mél sera alors automatiquement redirigé vers plus.pratique@gmail.com
  3. Gmail va alors vérifier à son tour le domaine émetteur, le mél n'arrive pas de observatoire.nice, car l'IP correspond à obspm.fr ! C'est incohérent donc gmail refuse le mél et fait baisser la réputation de obspm.fr, car ce site est considéré comme émetteur à risque.

Vous ne recevrez jamais le mél et l'expéditeur recevra un message incompréhensible :

Remote host said: 550-5.7.26 This message does not pass authentication checks (SPF and DKIM both
550-5.7.26 do not pass). SPF check for [observatoire.nice] does not pass with ip:
550-5.7.26 [145.238.193.20].To best protect our users from spam, the message has
550-5.7.26 been blocked. Please visit
550-5.7.26  https://support.google.com/mail/answer/81126#authentication for more
550 5.7.26 information. i63-20020a638742000000b00502e6e5b580si1388133pge.756 - gsmtp

À vous de voir si vous souhaitez prendre le risque de perdre des méls Et si vous recevez un jour ce type d'erreur en retour c'est que votre destinataire redirige ses méls.

« J'ai testé ma redirection donc c'est bon ! »

Vous avez mis en place une redirection de votre.mél@obspm.fr vers perso@orange.fr. Si vous demandez à un collègue de l'Obs de vous envoyer un mél de test, c'est normal que la redirection fonctionne. La vérification de domaine sera cohérente, même après le rebond. Il n'en sera pas forcément de même pour un mél extérieur.

Suivant la politique mise en place au niveau du serveur mél de destination, une anomalie ne classe pas forcément le mél en spam. Il peut simplement baisser sa note. Si le mél contient un lien extérieur, la note peut encore baisser ; s'il est en HTML, idem... Au final, certains méls peuvent passer et d'autres non, ou passer mais finir dans la boite spam sans raison apparente. Pas simple de s'y retrouver et vous ne pouvez pas connaître la politique de votre hébergeur[1], il vaut donc mieux jouer la prudence à ce sujet.

Pour terminer, de nombreux domaines tolèrent le rebond. La redirection fonctionne peut-être aujourd'hui, mais demain ?

Avez-vous toujours envie de prendre le risque ?

Problème du Mél en erreur

La DIO surveille les méls en erreur sur le serveur de messagerie. Le flot de messages d'erreurs lié aux redirections nous empêche de faire correctement notre travail. Exemple vécu : une université a changé son nom de domaine. Dans un tel cas, tous les messages envoyés depuis les listes reviennent en erreur. Nous le voyons grâce à une analyse des journaux des serveurs. Mais celle-ci est polluée par les redirections.

Problème du quota de messagerie et bilan carbone

Quand on redirige ses méls, on oublie souvent de supprimer le mél du serveur rebond. En d'autres termes, le mél est redirigé, mais il reste quand même physiquement dans la boite obspm.fr. Il est donc copié deux fois, prend le double de place et augmente le bilan carbone de l'opération.

Si l'utilisateur n'y prend pas garde, son volume augmente jusqu'à saturation. Le quota maximum est atteint et il finit par ne plus rien recevoir.

Accessoirement, chaque boite mél qui sature engendre des erreurs sur les serveurs, provoque ralentissements et plantages et entraine du travail de vérification pour la DIO.

Pensez à vos collègues qui eux aussi pâtiront de ces plantages et de ces ralentissements !

Utile ? Vraiment ?

Lorsqu'on redirige un mél, on redirige l'ensemble de son courrier sans se poser de question. C'est pratique certes.

Mais alors, pourquoi ne pas donner directement cette adresse aux contacts ? Pourquoi leur donner l'adresse @obspm.fr ou @cnrs.fr plutôt que directement @gmail.fr ? Auriez-vous honte de votre boite gmail ? Ou alors, vous trouvez que @obspm.fr ça fait quand même plus sérieux pour une adresse de chercheur ?

Dans ces conditions, à quoi bon s'embêter à rediriger et prendre tous les risques évoqués au-dessus ? Utilisez uniquement votre adresse professionnelle et soyez-en fier !

Quelle autre solution ?

Plutôt que de vous embêter à mettre en place toutes ces redirections, il vous suffit tout simplement de configurer dans votre client de messagerie comme Thunderbird, Mail ou Outlook l'ensemble de vos comptes. C'est simple, ça fonctionne mieux et c'est tout aussi pratique.

Sachez pour finir, que sur votre téléphone mobile, vous le faites déjà le plus souvent sans même vous en rendre compte. Par exemple lorsque vous configurez l'ensemble de vos boites sur l'application « mail » intégré aux Iphones. Pour les utilisateurs d'Android nous vous recommandons les clients K9-mail ou FairEmail.

réf: [1] La politique peut être visible en analysant l'entête des méls, mais il faut bien reconnaitre que c'est un charabia d'informaticien, une incantation anti-spam ?

Exemple pour un mél légitime classé spam :

X-Spam-Flag: YES
X-Spam-Status: Yes, score=5.0 required=5.0 tests=DATE_IN_FUTURE_24_48,
        DCC_CHECK,DCC_REPUT_90_94,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,
        DKIM_VALID_EF,FR_CLIC_ICI,HTML_FONT_LOW_CONTRAST,HTML_MESSAGE,
        MIME_HTML_ONLY,SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY
        autolearn=disabled version=3.4.6
X-Spam-Report:
        * -1.2 SPF_PASS SPF: sender matches SPF record
        *  0.2 DATE_IN_FUTURE_24_48 Date: is 24 to 48 hours after Received:
        *      date
        *  0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
        *  0.8 FR_CLIC_ICI BODY: Click here, in french
        *  1.5 MIME_HTML_ONLY BODY: Message only has text/html MIME parts
        *  0.0 HTML_FONT_LOW_CONTRAST BODY: HTML font color similar or
        *      identical to background
        *  0.0 HTML_MESSAGE BODY: HTML included in message
        * -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
        * -0.1 DKIM_VALID_EF Message has a valid DKIM or DK signature from
        *      envelope-from domain
        * -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
        *      author's domain
        *  0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily
        *       valid
        *  3.5 DCC_CHECK Detected as bulk mail by DCC (dcc-servers.net)
        *  0.4 DCC_REPUT_90_94 DCC reputation between 90 and 94 %
        *  0.0 UNPARSEABLE_RELAY Informational: message has unparseable relay
        *      lines