Héberger son courriel en 2018

Posté par (page perso) . Édité par Davy Defaud, ZeroHeure et olivierweb. Modéré par ZeroHeure. Licence CC by-sa.
27
5
mai
2018
Internet

Cette dépêche n’a pas vocation à parler de tous les aspects du courriel : certains ont déjà été évoqués précédemment comme la configuration de base, la gestion du spam ou la configuration TLS, par exemple. On pourrait aussi parler :

  • des fournisseurs de courriel qui limitent le nombre de courriels par seconde qu’ils acceptent en entrée (ce qui ralentit pas mal la distribution des messages sur une liste de diffusion, par exemple la lettre quotidienne de LinuxFr.org) ;
  • des divers filtres anti‐pourriel mis en place par les autres fournisseurs qui bloquent à tort des messages ;
  • des listes noires ou des DNSBL/RBL ;
  • des services d’adresse de courriel temporaire ;
  • des serveurs primaire et secondaire de courriel ;
  • etc.

Bref, le sujet est vaste. Il se dit que ce serait même un métier (et il se dit aussi que les professionnels et spécialistes se feront un plaisir de corriger ou compléter cette dépêche en cas d’oubli, d’erreur ou d’imprécision).

Mais quelle serait la problématique, disons… d’une association de bénévoles passionnés qui voudraient avoir leurs propres serveurs de courriel et de listes de diffusion, et qui voudraient interagir avec le reste du monde ?

Sommaire

Ici, on ne va pas raisonner en termes d’utilisateurs finals, d’émetteurs et de destinataires des courriels, mais en termes de serveurs de courriel. Intéressons‐nous à notre association fictive et baptisons ses serveurs/services linuxfr.example et lists.linuxfr.example (les deux pouvant être séparés ou fusionnés, ce qui a des conséquences sur les possibilités de redondance primaire et secondaire, ou la réécriture des alias par le gestionnaire de messagerie, sachant que l’on ne veut exposer que du @linuxfr.example).

On va causer SPF (qui peut émettre du courriel pour mon domaine), DKIM (authenticité du domaine expéditeur et intégrité du message) et DMARC (politique pour faire appliquer SPF et DKIM, et gérer les erreurs). La politique DKIM ou SPF peut être inexistante, tolérante (« si ce n’est pas comme prévu, ce n’est pas grave ») ou stricte (« si ce n’est pas comme prévu, veuillez rejeter ce courriel »).

Plusieurs cas se présentent à nous :

Schéma

Exemples de politiques

Politiques visibles dans les courriels reçus

L’en‐tête Authentication-Results dans le courriel reçu permet d’avoir une vision au niveau DKIM/SPF : par exemple, le champ spf pourra prendre des valeurs comme none (pas de politique), pass (OK), softfail (pas bon, mais tant pis), etc. Le champ dmarc pourra aussi prendre des valeurs none, pass ou fail. De même pour le champ dkim, on pourra trouver fail, neutral, none, pass, temperror, permerror. Évidemment, ça suppose que le courriel est reçu et non rejeté en amont…

Authentication-Results: someserver; auth=pass smtp.auth=xxxx
Authentication-Results: someserver; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=xxx header.i=xxx header.b=xxx;
Authentication-Results: someserver; dkim=fail reason="verification failed; insecure key"
Authentication-Results: someserver; dkim=neutral reason="verification failed; insecure key/testing"
Authentication-Results: someserver; dkim=none reason="no signature"; dkim-adsp=fail (insecure policy); dkim-atps=neutral
Authentication-Results: someserver; dkim=pass (1024-bit key; secure) header.d=xxx header.i=xxx header.b=xxx;
Authentication-Results: someserver; dkim=pass header.i=xxx header.s=xxx header.b=xxx;
Authentication-Results: someserver; dkim=pass reason="2048-bit key; unprotected key"
Authentication-Results: someserver; dkim=permerror (0-bit key) header.d=xxx header.i=xxx header.b=xxx;
Authentication-Results: someserver; dkim=permerror (bad message/signature format)
Authentication-Results: someserver; dkim=permerror reason="key not found"
Authentication-Results: someserver; dkim=temperror (0-bit key; unprotected) header.d=xxx header.i=xxx header.b=xxx;
Authentication-Results: someserver; dmarc=fail header.from=xxxx
Authentication-Results: someserver; dmarc=none header.from=xxxx
Authentication-Results: someserver; dmarc=pass header.from=xxxx
Authentication-Results: someserver; spf=none (sender IP is xx.xx.xx.xx) smtp.mailfrom=xxxx;
Authentication-Results: someserver; spf=pass (sender IP is xx.xx.xx.xx) smtp.mailfrom=xxxx
Authentication-Results: someserver; spf=softfail (sender IP is xx.xx.xx.xx) smtp.mailfrom=xxxx; dkim=fail (signature did not verify)

On va aussi trouver des informations intéressantes dans les en-têtes DKIM-Filter:, DKIM-Signature: et Received-SPF: (et aussi d’autres parfois comme X-DKIM:, X-Google-DKIM-Signature:, X-Original-DKIM-Signature:, X-Original-DMARC-Record:, etc.) :

DKIM-Filter: OpenDKIM Filter v2.11.0 mx2.ac-nancy-metz.fr 10D63249F
DKIM-Filter: OpenDKIM Filter v2.9.2 webmail.ntymail.com A4EC71E4121
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
Received-SPF: None (…)
Received-SPF: Pass (…)
Received-SPF: SoftFail (…)

Les politiques annoncées

Prenons les politiques annoncées (via DNS) pour (un des domaines des) dix fournisseurs de courriel les plus utilisés par nos visiteurs (plus linuxfr.org) :

Domaine SPF DMARC DKIM
gmail.com v=spf1 redirect=_spf.google.com / v=spf1 include:_netblocks.google.com (…) ~all v=DMARC1; p=none; sp=quarantine; rua=mailto:(…) k=rsa; p=(…2048 bits…)
free.fr N/A N/A N/A
yahoo.com v=spf1 redirect=_spf.mail.yahoo.com / v=spf1 ptr:yahoo.com ptr:yahoo.net ?all v=DMARC1; p=reject; pct=100; rua=mailto:(…); k=rsa; p=(…2048 bits…)
hotmail.com v=spf1 ip4:157.55.9.128/25 include:spf.protection.outlook.com (…) ~all v=DMARC1; p=none; sp=quarantine; pct=100; rua=mailto:(…); ruf=mailto:(…); fo=1 ?
laposte.net v=spf1 include:_spfbloc1.laposte.net (…) mx -all v=DMARC1;p=quarantine;sp=reject;rua=mailto:(…);ruf=mailto:(…);rf=afrf; v=DKIM1; k=rsa; p=(…2048 bits…)
wanadoo.fr N/A N/A N/A
orange.fr N/A N/A N/A
gmx.de v=spf1 ip4:213.165.64.0/23 (…) -all N/A
no-log.org N/A N/A N/A
protonmail.ch v=spf1 include:_spf.protonmail.ch ~all v=DMARC1; p=quarantine; fo=1; v=DKIM1; k=rsa; p=(…1024 bits…)
linuxfr.org v=spf1 a mx ~all v=DMARC1; p=none; fo=0; adkim=r; aspf=r; pct=100 v=DKIM1; k=rsa; p=(…2048 bits…)

On voit (enfin, si l’on sait un minimum lire les politiques) que l’on trouve un peu de tout, entre rien et tout, du tolérant au très strict (par exemple, pour SPF ?all est neutre, ~all signale uniquement les échecs et -all rejette).

Embrouillons tout ça

L’envoi entre tiers sans intérêt

alice.example envoie du courriel n’ayant aucun rapport avec linuxfr.example à bob.example. Rien de particulier à dire, et l’exemple est assez peu pertinent ici.

La réception directe

alice.example envoie du courriel à linuxfr.example, qui va respecter la politique SPF/DKIM de alice.example.

Cela couvre différents cas : les vraies boîtes d’utilisateurs, les boîtes techniques (postmaster@, root@, etc.). Et l’on peut inclure les échanges avec le gestionnaire de listes de diffusion lui‐même ([dés]abonnement, accès aux archives par courriel, etc.) ou tous les autres robots du même genre.

En revanche, si le courriel tente de se faire passer comme provenant de linuxfr.example (ou lists.linuxfr.example), c’est alors la même politique de linuxfr.example (ou de lists.linuxfr.example) qui sera respectée, conduisant vraisemblablement au rejet.

La réception sur alias pointant vers un autre domaine

alice.example envoie du courriel à l’adresse bob@linuxfr.example, qui est un alias de bobby@bob.example. linuxfr.example va se décider suivant la politique SPF/DKIM de alice.example ; et si ça passe, bob.example va voir arriver du courriel de linuxfr.example prétendant venir de alice.example. bob.example pourrait donc accepter ou rejeter suivant la politique SPF ou DKIM de alice.example (si les courriels en réponses partiront bien vers alice.example, le message de rejet sera en revanche bien reçu par linuxfr.example).

La réception sur une liste de discussion/diffusion

alice.example envoie du courriel à team@lists.linuxfr.example, qui est une liste de diffusion/discussion. linuxfr.example va se décider suivant la politique SPF/DKIM de alice.example. Et maintenant, il doit diffuser vers tous les abonnés à la liste. Deux grands choix s’offrent à lui :

  • il rajoute ses propres infos au courriel, mais sans modifier les infos initiales ; se faisant, il prétend être alice.example devant plein de fournisseurs différents, il court alors le risque que la politique SPF/DKIM de alice.example soit stricte et l’interdise ; auquel cas, il reçoit des messages de rejet et certains abonnés (ceux des fournisseurs qui respectent les politiques DKIM/SPF) ne recevront pas le message initial ;
  • il modifie le courriel pour dire que c’est lui qui l’envoie ; auquel cas, il est plus ou moins difficile de répondre à alice.example (le nom ou l’adresse peuvent être masqués par exemple).

Par exemple, voir le paramétrage DKIM et DMARC pour Sympa (version >= 6.1).

L’envoi direct

linuxfr.example envoie un courriel à alice.example, qui peut (ou non) le vérifier par rapport à la politique SPF/DKIM de linuxfr.example. Dans cette catégorie, on va trouver les envois depuis les comptes des utilisateurs, les envois automatiques (cron par exemple) et autres robots.

L’envoi depuis le mauvais serveur à un tiers

alice.example envoie du courriel à bob.example en prétendant envoyer un message de la part de admin@linuxfr.example (ça peut être légitime s’il s’agit de l’utilisateur admin@linuxfr.example qui envoie son courriel via son propre fournisseur alice.example ou ça peut être frauduleux, comme un spammeur usurpant cette adresse par exemple). Si bob.example ne prend pas de précautions particulières, le message sera diffusé. Si maintenant bob.example respecte la configuration SPF ou DKIM de linuxfr.example, alors le message pourra être rejeté (suivant ladite configuration). En revanche, on voit que linuxfr.example ne peut pas faire grand‐chose si bob.example ne respecte pas la politique qui a été mise en place.

L’envoi depuis le gestionnaire de listes de diffusion

lists.linuxfr.example peut transiter par linuxfr.example pour envoyer un courriel à alice.example, qui peut (ou non) vérifier les politiques SPF/DKIM des deux domaines. Dans cette catégoire, on va trouver par exemple l’envoi de la version agrégée des échanges d’une liste de diffusion.

Conclusion

Normalement, à ce stade, vous devriez vous dire que le courriel en 2018 c’est trivial et mettre en place votre propre infrastructure, avec serveur d’envoi et serveur de listes de discussion… Ou vous poser des questions du type : puis‐je utiliser la politique SPF d’un domaine pour écrire sur un alias, me faire rejeter volontairement mon courriel et en déduire le domaine de l’adresse cachée derrière l’alias. Ou bien avoir envie d’une aspirine.

C’est là que je replacerai subrepticement cet extrait de l’introduction de cette dépêche :

« Bref, le sujet est vaste. Il se dit que ce serait même un métier (et il se dit aussi que les professionnels et spécialistes se feront un plaisir de corriger ou compléter cette dépêche en cas d’oubli, d’erreur ou d’imprécision). »

Et que je rappellerai qu’une association de bénévoles passionnés ayant ses propres serveurs de courriel et de listes de diffusion rencontre parfois deux ou trois difficultés, mais que c’est très formateur. C’est d’ailleurs l’origine de cette dépêche : un courriel envoyé sur une liste LinuxFr.org depuis un domaine avec une politique SPF stricte, relayé par notre Sympa, et qui était rejeté par GMail ; ainsi qu’une lettre quotidienne qui était subitement classée comme pourriel par Free, ce qui a entraîné une relecture et une modification de notre configuration.

  • # C'est mal, mais je l'ai quand même fait ...

    Posté par . Évalué à 0.

    <warning>
    J'ai pas tout lu. Ça aussi c'est mal ... Plus tard, promis ...
    </warning>
    
    <warning>
    Je cause trop, je sais.
    </warning>
    
    <warning>
    Et je suis peut-être un peu hors sujet. C'est pas bien non plus ...
    Ceci étant dit !
    </warning>
    

    Intéressant tout ça !

    Je me permets d'ajouter mon expérience perso, dans le contexte suivant : il y a quelques années, ma boite est passée chez Google pour les mails et tout ce qui va avec.
    Cool, c'était vachement mieux que GroupWise. J'espère que vous ne connaissez pas GroupWise …

    Sauf qu'on se lasse assez vite de l'interface Web de Google …
    N'étant pas du genre à me laisser faire par les admins officiel, je creuse un peu …
    Je précise au passage que je suis dév. plutôt Linux et embarqué. Admin, c'est pas un Full Time Job © …

    Dans un premier temps, je remarque qu'on a le droit au forward systématique. J'ai donc créé un compte "boulot" sur mon "serveur perso à ma maison chez moi".
    Au moins, je peux utiliser mon vaillant Thunderbird pour la lecture des mails.
    Même si je ne pouvais pas en envoyer en tant que "moi au boulot", Thunderbird a prouvé son utilité quand il m'a retrouvé un mail que Google lui-même n'arrivait pas à trouver. J'étais certain de l'existence du mail, mais impossible de remettre la main dessus avec l'interface Google. C'est quoi déjà leur cœur de métier ?… No problemo avec Thunderbird !

    Bon, ça va un moment cette histoire, mais la réception sans l'émission, ça devient aussi lassant.
    Ça me travaille, j'en cause à mes potes qui sont admins, eux, des véritables … Ils me disent "ouais, on peut tout faire avec postfix". Un peu plus tard, je google à nouveau, et, je sais pas pourquoi, ce jour là, j'ai les résultats que j'espérais …
    La question, c'était : est-ce que je peux me faire passer pour ma boite (et indirectement pour Google).

    La réponse est oui. Je ne vais pas la détailler. Et d'une, Google devrait être autant votre ami que pour moi. Et de deux, c'est vraiment trop facile en fait !

    Et donc, maintenant, je peux recevoir et envoyer des messages à partir de mon serveur perso, comme si je n'utilisais que l'interface Google pro.
    En plus schématique, ça donne ça :
    - un mail reçu sur moi@pro est forwardé à moi@perso
    - un mail envoyé par moi@pro, mais à partir de perso, arrive au destinataire avec un from en moi@pro …
    Ça fout les jetons, nan ?

    Évidemment, tout n'est pas parfait. On peut toujours tracer le chemin du mail jusque chez moi.
    Et ces histoires de SPF (que je ne maîtrise pas) ne passent pas totalement inaperçues. Mais en gros, Google dit : "hé, mais ton mail, là, il est pas clean, il vient pas de chez moi. Vas y, passe". Même pas besoin de truc Jedi …
    Après, j'ai bien quelques mails qui finissent dans les spams de mes destinataires, certes.

    Mais globalement, c'est royal ! Et affolant ! Bah oui, si moi qui suis une ouiche en mail, qui ne connais que les bases de la base, j'arrive à faire ça, mais n'importe qui peut se faire passer pour qui il veut, nan ?
    Oui, j'ai fait l'expérience, je me suis fait passé pour un collègue, un débutant des SI .. Il en fait encore pipi au lit !
    Après, j'ai été clean, je lui ai tout expliqué, ainsi qu'à son chef … Ils s'en foute … OK, je continue, ça m'arrange …

    • [^] # Re: C'est mal, mais je l'ai quand même fait ...

      Posté par . Évalué à 3.

      Bah c'est une faille très connue de conception du protocole SMTP, d'où les bidules que GMail et consorts rajoutent par dessus pour sauver les meubles.

      Je cite Wikipedia :

      Une des limitations de SMTP vient de l'impossibilité d'authentifier l'expéditeur. Pour ceci, l'extension SMTP-AUTH a été définie. Malheureusement, l'impossibilité d'imposer largement SMTP-AUTH a rendu ce protocole impuissant face au phénomène du spam.

      (ce n'est qu'un extrait)

      "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

    • [^] # Re: C'est mal, mais je l'ai quand même fait ...

      Posté par . Évalué à 6.

      Pourquoi n'avoir pas tout simplement configuré ton adresse pro dans Thunderbird ? Plus simple, plus rapide, plus efficace (pas de problèmes dû au fait que tu n'utilises pas le bon serveur).

      Et ensuite, ça dépends de la configuration aussi. Dans ton cas ça passe, dans le mien ça ne passerais que si le serveur de destination ignore complètement SPF et DKIM…

  • # Et que faire avec les correspondants hébergés par microsoft ?

    Posté par . Évalué à 10. Dernière modification le 05/05/18 à 22:45.

    J'ai beau avoir tout bien configuré comme il faut (SPF, DKIM, mais pas DMARC pour l'instant), enregistré l'adresse de mon serveur via leur service JMRP et SNDS, demandé que mon ip soit sortie de leur liste noire et en avoir reçu la confirmation, j'ai toujours certains correspondants dont le mail est chez microsoft (hotmail, outlook et consorts) qui ne reçoivent pas mes messages.

    Rien dans les spams, rien dans l'inbox !
    Le pire c'est qu'il n'y a pas de message d'erreur du serveur: les mails sont tout simplement passés à la trappe sans autre forme de retour utile.

    Le plus étrange c'est que cela n'est le cas que pour certains destinataires et pas tous ! j'ai décidé de ne me plus m'arracher les cheveux et de conseiller à ceux dont c'est le cas de prendre une deuxième adresse email chez un fournisseur moins problématique, mais ce n'est vraiment pas l'idéal, donc si certains ont une solution, je suis preneur.

    Framasoft a récemment indiqué qu'ils avaient eu des soucis avec les serveurs hotmail: si un des admins passait par là, pourrait-il nous expliquer comment il gère le cas microsoft ?

    merci

    • [^] # Re: Et que faire avec les correspondants hébergés par microsoft ?

      Posté par . Évalué à 2.

      Salut,
      J'ai eu le même problème que toi en 2015 (voir ici) et je suis aussi passé par la case SNDS, mais ça a fonctionné pour moi.
      Il m'arrive souvent d'avoir des problèmes avec Microsoft (1 fois par an en moyenne).

      • [^] # Re: Et que faire avec les correspondants hébergés par microsoft ?

        Posté par . Évalué à 2.

        Le SNDS me dit que mon IP a un status "normal", mais rien n'y fait: la seule réponse que je trouve en cherchant sur le web, c'est qu'il faut avoir une réputation positive. Mais je n'ai aucune idée de la manière dont cette réputation est évaluée et mesurée.

      • [^] # Re: Et que faire avec les correspondants hébergés par microsoft ?

        Posté par . Évalué à 5.

        Euh…

        Getting started
        To access SNDS, please log in with a Microsoft Account and then request access to the IPs for which you are >responsible. You'll be taken through a simple authorization process, and then you'll soon have access to a wealth of >information about those IPs.

        L'emphase est de moi.
        Pourquoi devrais-je créer un compte MS pour utiliser une adresse mail pas chez MS?!

      • [^] # Re: Et que faire avec les correspondants hébergés par microsoft ?

        Posté par . Évalué à 2.

        Personnellement, la dernière fois que j'ai eu le problème de trou noir avec hotmail (email soit disant acceptés mais apparaissant nul-part chez le destinataire) c'était parce-que mon serveur était pas synchronisé avec un serveur de temps et était 2 minutes en avance.

    • [^] # Re: Et que faire avec les correspondants hébergés par microsoft ?

      Posté par . Évalué à 6.

      Il n'y a pas de solution avec Microsoft (à part s'en passer). Les politiques de leurs serveurs de mails changent d'une semaine à l'autre, de manière imprévisible, avec des blacklistages plutôt opaques.

    • [^] # Re: Et que faire avec les correspondants hébergés par microsoft ?

      Posté par (page perso) . Évalué à 3.

      Idem pour moi, mais uniquement sur certaines adresses. Par exemple, alice@hotmail.com ne recevra pas mes emails, mais bob@hotmail.com les reçois sans problème.

      J'en ai conclu qu'ils ont une batterie de serveurs avec des configurations hétéroclites. Je ne prends soin de remplir les formulaires en ligne de que lorsque je dois vraiment contacter une personne, et qu'elle est bloquée sur une adresse MS…

      Du coup, je milite et propose d'autres hébergeurs, plus respectueux des standards (gmail pour l'instant).

    • [^] # Re: Et que faire avec les correspondants hébergés par microsoft ?

      Posté par (page perso) . Évalué à 5.

      Framasoft a récemment indiqué qu'ils avaient eu des soucis avec les serveurs hotmail: si un des admins passait par là, pourrait-il nous expliquer comment il gère le cas microsoft ?

      Ça dépend du problème dont tu parles :

      Je ne me rappelle pas d'un autre incident impliquant hotmail, mais ça ne veut pas dire qu'on n'a pas eu d'autres problèmes.

      Sinon on a SPF, DKIM et DMARC et quelques règles (voir à la fin de mon article) pour ne pas envoyer trop de mails par connexion pour certaines destinations (je te regarde, orange.fr). C'est obligatoire pour certains, je le mets en place par prudence pour d'autres.

      Malgré tout ça, on a de temps en temps des blocages :

      • laposte.net, où les serveurs tombent assez fréquemment (bonjour le sous-traitant dis donc)
      • facebook.com, qui décide de temps en temps de nous greylister 24/48h
      • free.fr, pareil, des fois ça leur prend de nous greylister 24/48h

      It's a fez. I wear a fez now. Fezes are cool !

  • # DMARC redondant avec SPF/DKIM ?

    Posté par . Évalué à 2.

    Sur un champ SPF, on peut indiquer quoi faire des adresses qui n'y sont pas présentes (~all, ?all ou -all). Avec DKIM, on peut ajouter un champ ADSP.

    Du coup, DMARC a-t-il une utilité si on ne souhaite pas un controle plus fin (pct) ni recevoir d'alertes ?

    • [^] # Re: DMARC redondant avec SPF/DKIM ?

      Posté par (page perso) . Évalué à 4.

      Du coup, DMARC a-t-il une utilité si on ne souhaite pas un controle plus fin (pct) ni recevoir d'alertes ?

      DMARC n’est pas redondant avec SPF/DKIM, mais il est conçu pour remplacer ADSP, et est donc effectivement partiellement redondant avec ce dernier.

      DMARC is designed to replace ADSP by adding support for: wildcarding or subdomain policies, non-existent subdomains, slow rollout, SPF, quarantining mail.

      (DMARC Overview)

      Voir aussi l’annexe A.5 du RFC 7489 :

      DMARC has been characterized as a "super-ADSP" of sorts.

      Et concrètement, DMARC a une utilité en ce sens que les « gros » fournisseurs de messagerie commencent à l’exiger pour accepter des mails entrants en provenance des manants…

  • # Vous ne voulez peut-être pas exécuter votre propre serveur de messagerie

    Posté par (page perso) . Évalué à -5.

    Salut, je suis juste un débutant ici. Je veux dire que ce n'est pas trop difficile de configurer un serveur de messagerie auto-hébergé, mais il n'est pas facile de configurer votre serveur de messagerie pour envoyer vos emails à la boîte de réception au lieu du dossier spam / indésirable.
    Nous utilisons toujours un service tiers pour envoyer nos e-mails de commerce électronique (Mailgun, Amazon SES), les messages système (Gmail). Taux de boîte de réception: 30-40%!

    Mes clients semblent être intéressés par mon article sur Gmail SMTP Setting

    Regardez ceci - Votre email que vous m'avez envoyé est dans le dossier Spam :

    Titre de l'image

  • # Le mail, c'est facile

    Posté par (page perso) . Évalué à 3.

    Franchement, je ne comprends pas le problème que les gens ont avec l'hébergement mail. J'ai toujours trouvé ça facile et j'ai que rarement eu des problèmes. Jusqu'à présent j'utilisais une solution exim + dovecot maison avec un record SPF -all. J'ai jamais remarqué des problèmes sauf a un certain moment où le bon coin envoyait des e-mails avec un expéditeur d'envelope qui correspondait a ton mail perso, qui bloquait sur la politique SPF. Mais plus maintenant.

    J'ai jamais remarqué de blacklist ou autre…

    Maintenant, j'utilise Mailu qui me donne entière satisfaction et qui me permet d'avoir DKIM en bonus. J'avoue l'avoir un peu customisé. Ma boîte mail perso est un wildcard sur le domaine. Et je suis la seule personne sur ce serveur mail. C'est peut être pour ça que je n'ai pas trop de soucis.

    • [^] # Re: Le mail, c'est facile

      Posté par (page perso) . Évalué à -1.

      J’avoue partager cette perplexité… Le mail a toujours parfaitement fonctionné sur mon serveur, en tout cas depuis que je passe par le « smarthost » de mon FAI pour les envois. Et ça n’empêche pas la configuration SPF ;-)

      Avant, j’utilisais Exim+Courrier/Debian, maintenant c’est Exim+Dovecot/Archlinux, mais ça ne change rien au bon fonctionnement.

      • [^] # Re: Le mail, c'est facile

        Posté par (page perso) . Évalué à 10.

        en tout cas depuis que je passe par le « smarthost » de mon FAI pour les envois

        Oui si on délègue une bonne partie des trucs les plus chiants et piégeux à un pro, ça marche. J'ai entendu dire que ça marche parfaitement quand on utilise gmail aussi !

        • [^] # Re: Le mail, c'est facile

          Posté par (page perso) . Évalué à 1.

          Ta comparaison avec gmail est complètement hors-sujet : en gérant tout ton mail mais en faisant passer les envois par le smarthost du FAI, tu gardes le plein contrôle de ta configuration, de ton degré de sécurisation, etc. Le smarthost n'est guère plus qu'un proxy, que ton fournisseur d'accès à Internet te mets à disposition gratuitement pour te fournir l'accès à la messagerie. Rien de choquant là dedans.

          Ensuite, la question n'est pas de se débarrasser de quoi que ce soit. C'est un choix pragmatique pour concilier avec une réalité incontournable : l'adresse IP(v4) que te donne ton FAI est typée "résidentielle" et tu n'y pourra jamais rien. Or ces IP résidentielles sont bloquées par les "grands hébergeurs", qui supposent que tout mail directement issu d'une IP résidentielle vient probablement d'un botnet…

          À mon avis, ce qui est choquant n'est pas en soi l'usage d'un smarthost, mais plutôt que nous n'ayons pas le choix (sauf avec de la patience si tu as la chance d'avoir une IP fixe, ce qui n'est pas mon cas).

          • [^] # Re: Le mail, c'est facile

            Posté par (page perso) . Évalué à 3.

            Ta comparaison avec gmail est complètement hors-sujet

            Utiliser gmail comme SMTP smarthost : https://support.google.com/a/answer/2956491?hl=fr

            Ensuite, la question n'est pas de se débarrasser de quoi que ce soit.

            Non bien sûr, dans un journal qui parle des problématiques de "réputation" auxquelles on peut faire face en tant que SMTP, passer par un relais pour avoir sa réputation au lieu de gérer la sienne propre, c'est ne se débarrasser de rien, non.

            Or ces IP résidentielles sont bloquées par les "grands hébergeurs", qui supposent que tout mail directement issu d'une IP résidentielle vient probablement d'un botnet…

            Je dois être vachement balèze pour que mon IP résidentielle ne soit pas blacklistée chez Yahoo, Microsoft…


            Bon je pense qu'il est temps d'arrêter hein, c'est déjà bien d'avoir su monter un proxy SMTP vers son FAI, ça serait dommage de tout gâcher en racontant plus de conneries.

            • [^] # Re: Le mail, c'est facile

              Posté par (page perso) . Évalué à 0.

              J'espère que nous avons une communication intéressante au lieu d'être trop nerveuse :) J'aime vraiment ce sujet, même si je n'y consacre pas beaucoup de temps.

              Dans le commerce électronique, j'évalue l'efficacité de l'envoi de courrier en fonction de la disponibilité du courrier électronique, des tarifs de la boîte de réception et des taux de rebond. Chaque mois, nous envoyons environ 50000 à 100000 emails, et je me rends compte que le serveur de messagerie auto-hébergé n'est pas bon comme nous le souhaitons.

              En supposant que nous envoyons 100 courriels, si nous utilisons un serveur auto-hébergé, il y aura environ 95 courriels atteignant le destinataire, 20 courriels arrivant dans la boîte de réception.
              Dans le cas d'utilisation d'AWS SES / Mailgun, il y a environ 25 à 30 courriels à recevoir avec le même contenu.

              Je suis prêt à payer des frais pour des courriels supplémentaires de 5 à 10 dans la boîte de réception du client.

            • [^] # Re: Le mail, c'est facile

              Posté par (page perso) . Évalué à 1.

              Utiliser gmail comme SMTP smarthost : https://support.google.com/a/answer/2956491?hl=fr

              Ah… au temps pour moi. Je ne m’y risquerais pas, toutefois : c’est Google, déjà, et puis c’est un relai filtrant :-( mais bon, peut-être qu’il y en a à qui ça sert…

              […] dans un journal qui parle des problématiques de "réputation" […]

              Tu restreins artificiellement le périmètre. Le sujet du journal est « Héberger son courriel en 2018 », et le contenu parle de SPF, DKIM, etc. ; toutes choses sur lesquelles tu as la main même si tu utilises un smarthost.

              Et puisque tu parles de réputation, justement, une association qui souhaiterait héberger son mail (car c’est là l’objet de l’article) pourrait être intéressée de savoir que les problèmes de réputation sont quasi-inexistants en passant par un smarthost correct.

              […] pour que mon IP résidentielle ne soit pas blacklistée […]

              Ceci suppose d’avoir une IP fixe ; je n’ai pas cette chance…
              Mais il est vrai qu’une association se tournerait vraisemblablement vers un hébergement proposant une IP fixe, ce qui ouvre en effet la possibilité de démarcher les différents acteurs pour augmenter progressivement la réputation de sa propre IP.

      • [^] # C’est Free, mais c’est pas grave

        Posté par . Évalué à 3.

        Le mail a toujours parfaitement fonctionné sur mon serveur, en tout cas depuis que je passe par le « smarthost » de mon FAI pour les envois.

        Alors tu ne dois pas être chez Free.

        Free est capable de te refuser l’envoi d’un mail parfaitement légitime d’après son contenu (grâce à un analyseur de contenu « intelligent »), même si on s’est authentifié sur le serveur SMTP (ça arrive plutôt avec des mails courts).
        Corollaire : Free rejette aussi des messages légitimes en entrée.

        C’est sûr, si on se moque de faire des faux positifs, c’est facile de lutter contre le spam : on peut même refuser tous les mails et c’est gagné, plus aucun spam.

        En général, les analyseurs de contenus sont utilisés sur les serveurs mail uniquement pour marquer les messages comme spam ou les classer dans le dossier spam, parce que bon, c’est pas fiable à 100 %, tout le monde le sait.

        Théorie du pot-au-feu : « tout milieu où existe une notion de hauteur (notamment les milieux économique, politique, professionnels) se comporte comme un pot-au-feu : les mauvaises graisses remontent. »

        • [^] # Re: C’est Free, mais c’est pas grave

          Posté par (page perso) . Évalué à 2.

          > Le mail a toujours parfaitement fonctionné sur mon serveur, en tout cas depuis que je passe par le « smarthost » de mon FAI pour les envois.

          Alors tu ne dois pas être chez Free.

          En effet. J’ai testé SFR puis Bouygues mais j’en ai « démarché » d’autres. Avant de changer de FAI, je me renseigne du mieux que je peux auprès de la hotline et dans les forums pour connaitre la politique du FAI quant au « port 25 » (en entrée) et au smarthost (en sortie).

    • [^] # Re: Le mail, c'est facile

      Posté par . Évalué à 3.

      Et je suis la seule personne sur ce serveur mail. C'est peut être pour ça que je n'ai pas trop de soucis.

      Oui. J'ai aussi un serveur mail que je suis seul à utiliser, et pour lequel je n'ai eu quasiment aucun problème en 10 ans. À côté de ça, j'ai travaillé sur des serveurs mail mutualisés, c'est beaucoup moins joyeux…

    • [^] # Re: Le mail, c'est facile

      Posté par (page perso) . Évalué à 2.

      Franchement, je ne comprends pas le problème que les gens ont avec l'hébergement mail.

      C'est qui pour toi « les gens » ?

      Parce que la plupart des « gens » que je connais utilisent tous le jours, voire plusieurs fois par jour, un moteur de recherche pour aller sur le même site, genre leur banque.

      Je vois mal ces « gens » là gérer leur propre hébergement mail.

  • # Micro-erreur

    Posté par . Évalué à 0.

    Hello les modérateurs,

    Petite erreur à signaler dans le tableau de la section "Les politiques annoncées" : la 4ième colonne indique "SPF" au lieu de "DKIM".

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.