Héberger son courriel en 2018

Posté par Benoît Sibaud (site web personnel) le 05 mai 2018 à 19:52. Édité par Davy Defaud, ZeroHeure et olivierweb. Modéré par ZeroHeure. Licence CC By‑SA.

Étiquettes :

mai

2018

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

Exemples de politiques
- Politiques visibles dans les courriels reçus
- Les politiques annoncées
Embrouillons tout ça
Conclusion

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.

Aller plus loin

Blog de Seboss666 : Faire du mail en 2018, c’est une tannée… (975 clics)
DLFP: Héberger son courriel (2013) (268 clics)
Breaking DKIM - on Purpose and by Chance (2017) (144 clics)

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

Posté par AncalagonTotof le 05 mai 2018 à 22:34. É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 xcomcmdr le 05 mai 2018 à 22:41. É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 Breizh le 06 mai 2018 à 10:10. É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 Anonyme le 05 mai 2018 à 22:42. Évalué à 10. Dernière modification le 05 mai 2018 à 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 Tetsumaki le 06 mai 2018 à 00:19. É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 Anonyme le 06 mai 2018 à 01:09. É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 Tetsumaki le 14 mai 2018 à 19:54. Évalué à 2.
      
      Tu devrais réussir à t'en sortir en passant par ce formulaire de contact : http://go.microsoft.com/fwlink/?LinkID=614866.
      
      Généralement et si tout est bien configuré, tu as une première investigation bateau te disant que ce n'est pas déblocable (1er email), tu réponds en anglais avec des détails, c'est escaladé (2eme email), t'attends, c'est débloqué (3eme email).
  - [^] # Re: Et que faire avec les correspondants hébergés par microsoft ?
    
    Posté par Maclag le 06 mai 2018 à 06:11. É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 rboudin le 06 mai 2018 à 11:48. É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 Léo le 06 mai 2018 à 11:37. É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 Andre Rodier (site web personnel) le 06 mai 2018 à 18:31. É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 Framasky (site web personnel) le 14 mai 2018 à 10:58. É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 :
  - le grand classique : IP pas connue, hotmail refuse. => aller sur https://support.microsoft.com/en-us/getsupport?oaspworkflow=start_1.0.0.0&wfname=capsub&productkey=edfsmsbl3&locale=en-us&ccsid=635895147582758202 pour demander le déblocage.
  - plus chiant : on a (relativement) récemment changé notre Sympa de serveur et on s'est retrouvé avec une IP avec une réputation moisie. C'était parce que notre hébergeur venait d'acheter un gros range d'IP, et il s'avère qu'il avait une réputation moisie. Un ticket au support plus tard, l'hébergeur a demandé une remise à zéro de la réputation du range d'IP.
  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
  Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.
# DMARC redondant avec SPF/DKIM ?

Posté par kna le 06 mai 2018 à 03:31. É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 gouttegd le 06 mai 2018 à 10:54. É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…
# Commentaire supprimé

Posté par natalia le 06 mai 2018 à 05:04. Évalué à -5. Dernière modification le 03 avril 2021 à 21:59.

Ce commentaire a été supprimé par l’équipe de modération.
- [^] # Re: Vous ne voulez peut-être pas exécuter votre propre serveur de messagerie
  
  Posté par Benoît Sibaud (site web personnel) le 06 mai 2018 à 20:23. Évalué à 3.
  
  Votre email que vous m'avez envoyé est dans le dossier Spam :
  
  Quelles sont les raisons de ce classement selon le prestataire utilisé ?
  - [^] # Commentaire supprimé
    
    Posté par natalia le 14 mai 2018 à 17:59. Évalué à 0. Dernière modification le 03 avril 2021 à 21:59.
    
    Ce commentaire a été supprimé par l’équipe de modération.
# Le mail, c'est facile

Posté par Mildred (site web personnel) le 06 mai 2018 à 22:55. É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 Yves (site web personnel) le 08 mai 2018 à 15:43. É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 Sufflope (site web personnel) le 08 mai 2018 à 15:51. É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 Yves (site web personnel) le 09 mai 2018 à 17:13. É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 Sufflope (site web personnel) le 14 mai 2018 à 22:14. É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.
        
        [^] # Commentaire supprimé
        
        Posté par natalia le 15 mai 2018 à 03:36. Évalué à 0. Dernière modification le 03 avril 2021 à 21:59.
        
        Ce commentaire a été supprimé par l’équipe de modération.
        
        [^] # Re: Le mail, c'est facile
        
        Posté par Yves (site web personnel) le 15 mai 2018 à 17:45. É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 Arthur Accroc le 11 mai 2018 à 13:22. É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.
    
    « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
    - [^] # Re: C’est Free, mais c’est pas grave
      
      Posté par Yves (site web personnel) le 14 mai 2018 à 10:39. É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 kna le 09 mai 2018 à 10:37. É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 cozo le 09 mai 2018 à 13:56. Évalué à -1.
    
    Depuis cette année j utilise modoboa : https://modoboa.org/fr/features/
    Et c'est top vraiment
- [^] # Re: Le mail, c'est facile
  
  Posté par Maz (site web personnel) le 11 mai 2018 à 12:49. É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 eltoniodelavega le 18 mai 2018 à 08:29. É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".
- [^] # Re: Micro-erreur
  
  Posté par Benoît Sibaud (site web personnel) le 19 mai 2018 à 10:29. Évalué à 3.
  
  Corrigé, merci.

Suivre le flux des commentaires

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