Sécurisations et normes email : Différence entre versions

De
Sauter à la navigation Sauter à la recherche
m (typo)
 
(3 révisions intermédiaires par le même utilisateur non affichées)
Ligne 28 : Ligne 28 :
 
<h3>HELO</h3>
 
<h3>HELO</h3>
 
Le "HELO" est le message de présentation envoyé par un serveur SMTP. Afin d'atteindre un niveau de confiance correct, ce HELO doit répondre à plusieurs critères :
 
Le "HELO" est le message de présentation envoyé par un serveur SMTP. Afin d'atteindre un niveau de confiance correct, ce HELO doit répondre à plusieurs critères :
* Il doit être un FQN (nom de domaine ou sous-domaine) valide, pointant vers l'IP du serveur SMTP envoyant le mail
+
* Il doit être un FQDN (nom de domaine ou sous-domaine) valide, pointant vers l'IP du serveur SMTP envoyant le mail
 
* Ce nom doit être identique correspondre au rDNS (reverse DNS) de l'IP du serveur SMTP.
 
* Ce nom doit être identique correspondre au rDNS (reverse DNS) de l'IP du serveur SMTP.
 +
* Ce rDNS ne doit PAS être sous la forme par défaut IPReversed.provider.tld car un serveur SMTP n'ayant pas un rDNS personnalisé a de fortes propensions à être un botnet émettant du spam.
  
 
En somme il faut choisir un nom (en général le nom d'hôte de la machine contenant le serveur SMTP), mettre ce nom en reverse DNS de l'IP du serveur, et demander au serveur de mails d'indiquer ce nom en HELO.
 
En somme il faut choisir un nom (en général le nom d'hôte de la machine contenant le serveur SMTP), mettre ce nom en reverse DNS de l'IP du serveur, et demander au serveur de mails d'indiquer ce nom en HELO.
Ligne 51 : Ligne 52 :
 
* Si elle contient une règle SPF qui n'est pas respectée, alors si cette règle est stricte (-all) le mail a d'énormes chances d'être rejeté, et si cette règle est non stricte (~all), le mail risque d'être considéré comme du spam, d'être rejeté, ou peut passer normalement, au choix du serveur de réception.
 
* Si elle contient une règle SPF qui n'est pas respectée, alors si cette règle est stricte (-all) le mail a d'énormes chances d'être rejeté, et si cette règle est non stricte (~all), le mail risque d'être considéré comme du spam, d'être rejeté, ou peut passer normalement, au choix du serveur de réception.
  
<h4>Règle SPF par défaut HaiSoft</h4>
+
<h4>Règle SPF HaiSoft</h4>
 
La règle SPF par défaut d'HaiSoft est :
 
La règle SPF par défaut d'HaiSoft est :
 +
 +
<pre>v=spf1 a mx include:spf.haisoft.net -all</pre>
 +
 +
<h4>Ancienne règle SPF par défaut HaiSoft</h4>
  
 
Pour Paris :  
 
Pour Paris :  
Ligne 108 : Ligne 113 :
 
<pre>_DMARC TXT v=DMARC1; p=reject; fo=0; adkim=r; aspf=s; pct=100; ri=86400; sp=reject</pre>
 
<pre>_DMARC TXT v=DMARC1; p=reject; fo=0; adkim=r; aspf=s; pct=100; ri=86400; sp=reject</pre>
  
Une telle valeur permet de rejeter tous les mails ne respectant pas SPF mais laisse passer en cas de souci DMARC, elle permet aussi de ne pas accepter l'envoi de mails en tant qu'un sous-domaine de votre domaine. C'est donc un gage de sécurité non négligeable pour votre domaine.
+
Une telle valeur permet de rejeter tous les mails ne respectant pas SPF mais laisse passer en cas de souci DKIM, elle permet aussi de ne pas accepter l'envoi de mails en tant qu'un sous-domaine de votre domaine. C'est donc un gage de sécurité non négligeable pour votre domaine.
  
 
D'autres champs existent pour recevoir des rapports des mails envoyés en tant que votre domaine vers les différents prestataires de mails.
 
D'autres champs existent pour recevoir des rapports des mails envoyés en tant que votre domaine vers les différents prestataires de mails.
 
Cet article vous donnera plus d'informations : https://help.returnpath.com/hc/fr/articles/222437867-Quelles-sont-les-diff%C3%A9rentes-balises-d-un-enregistrement-DMARC-
 
Cet article vous donnera plus d'informations : https://help.returnpath.com/hc/fr/articles/222437867-Quelles-sont-les-diff%C3%A9rentes-balises-d-un-enregistrement-DMARC-

Version actuelle datée du 18 novembre 2020 à 08:59

Sécurisations et normes email

La réception et la sécurisation des emails se fait principalement par des règles DNS présentes pour votre domaine.

MX: Serveur de réception des emails

La réception des emails ne peut se faire que si une entrée de type "MX" est présente dans la zone DNS du domaine. Cette entrée MX correspond au serveur SMTP de réception de mails. Le MX est par convention un nom canonique et non une adresse IP.


Exemple:

Soit le domaine "monsite.tld" dont les emails sont hébergés chez HaiSoft sur le serveur srv12.haisoft.net

  • Nous pouvons ajouter une entrée MX utilisant le nom d'hôte de la machine hébergeant le domaine :

MX 0 srv12.haisoft.net

Nous conseillons cette méthode car srv12.haisoft.net est également le serveur POP/IMAP/SMTP à utiliser pour vos connexions sécurisées, car le nom d'hôte contient les certificats SSL/TLS permettant de se connecter de manière sécurisée au serveur.

  • Ou bien nous pouvons ajouter un sous-domaine et l'assigner en MX
mail A 154.41.66.12
MX 0 mail.monsite.tld

Sécurité

Bien que les normes relatives aux emails parviennent difficilement à être universalisées, quelques standards sont de plus en plus utilisés afin de :

  • Diminuer la réception de spams
  • Limiter au maximum l'usurpation d'identité

HELO

Le "HELO" est le message de présentation envoyé par un serveur SMTP. Afin d'atteindre un niveau de confiance correct, ce HELO doit répondre à plusieurs critères :

  • Il doit être un FQDN (nom de domaine ou sous-domaine) valide, pointant vers l'IP du serveur SMTP envoyant le mail
  • Ce nom doit être identique correspondre au rDNS (reverse DNS) de l'IP du serveur SMTP.
  • Ce rDNS ne doit PAS être sous la forme par défaut IPReversed.provider.tld car un serveur SMTP n'ayant pas un rDNS personnalisé a de fortes propensions à être un botnet émettant du spam.

En somme il faut choisir un nom (en général le nom d'hôte de la machine contenant le serveur SMTP), mettre ce nom en reverse DNS de l'IP du serveur, et demander au serveur de mails d'indiquer ce nom en HELO.

Un mail ne répondant pas à ces critères est généralement considéré comme spam.

Nos serveurs sont configurés pour rejeter les emails n'ayant pas un HELO correct, car cela est le minimum à respecter lorsque l'on envoie un email. Si l'expéditeur n'est pas en mesure de corriger sa configuration, nous pouvons en dernier recours whitelister son adresse pour que vous receviez ses emails, mais cela anihile alors toute possibilité de vérification de l'authenticité de l'expéditeur, c'est donc extrêmement non recommandé.

HaiSoft met tout en oeuvre pour fournir un HELO correct et ainsi permettre la meilleure délivrabilité de vos mails. Tout mail envoyé par votre serveur HaiSoft est configuré pour posséder un HELO correct. Si vous détectiez toutefois une anomalie à ce niveau, n'hésitez pas à nous contacter par ticket support.


SPF (Sender Policy Framework)

SPF permet de définir les serveurs habilités à relayer les emails d'un domaine. Cette règle est présente sous forme de règle TXT dans la zone DNS du domaine. Cela permet d'éviter qu'une tierce personne envoie des emails à votre nom. Cela signifie également qu'il faut utiliser un serveur habilité à vous authentifier pour envoyer vos emails, sinon ces derniers n'ont aucune valeur d'authentification et seront donc rejetés.

Fonctionnement d'SPF

Lorsqu'un prestataire de mails reçoit un mail provenant de votre domaine, il vérifie donc si la zone DNS du domaine emétteur du mail contient une règle SPF :

  • Si la zone DNS contient une règle SPF et qu'elle est respectée, tout va bien.
  • Si elle n'en contient pas, alors le mail peut passer, mais sa chance de tomber dans les spams augmente.
  • Si elle contient une règle SPF qui n'est pas respectée, alors si cette règle est stricte (-all) le mail a d'énormes chances d'être rejeté, et si cette règle est non stricte (~all), le mail risque d'être considéré comme du spam, d'être rejeté, ou peut passer normalement, au choix du serveur de réception.

Règle SPF HaiSoft

La règle SPF par défaut d'HaiSoft est :

v=spf1 a mx include:spf.haisoft.net -all

Ancienne règle SPF par défaut HaiSoft

Pour Paris :

v=spf1 +a +mx ip4:154.41.66.0/23 ip4:149.71.232.0/22 include:relay.mailchannels.net -all

Pour Tours :

v=spf1 +a +mx ip4:185.177.44.0/24 ip4:91.212.26.0/24 include:relay.mailchannels.net -all


Syntaxe SPF

Pour la règle SPF par défaut d'HaiSoft :

  • v=spf1 permet d'indiquer qu'il s'agit d'une règle SPF
  • +a permet d'autoriser le serveur du domaine principal à émettre des mails pour le domaine
  • +mx permet d'autoriser le serveur de réception de mails du domaine à émettre des mails pour le domaine
  • ip4:154.41.66.0/23 ip4:149.71.232.0/22 permettent d'autoriser les deux IP ranges les plus courant d'HaiSoft à envoyer des emails
  • include:_spf.google.com include:relay.mailchannels.net permettent d'autoriser Gmail et notre partenaire relai de mails MailChannels à transférer des emails pour le domaine.
  • ~all permet d'indiquer que d'autres serveurs peuvent être amenés à éventuellement envoyer des emails.
  • -all serait une règle plus stricte que ~all, elle indiquerait qu'aucun autre serveur que ceux cités dans la zone SPF n'a le droit d'envoyer d'emails pour le domaine.

Erreurs SPF courantes

  • Lorsque l'on vous fournit une règle SPF à ajouter, il ne faut pas créer une nouvelle entrée, mais éditer votre règle existante.
  • Si vous avez plusieurs règles SPF, l'une ou l'autre sera aléatoirement lue par vos destinataires, pouvant causer le rejet de vos emails.
  • Il ne faut pas utiliser un relai SMTP qui n'est pas autorisé dans votre règle SPF. Seul votre serveur hébergeant les emails et étant capable de vous authentifier est habilité à envoyer des emails pour votre domaine. Vos mails risquent d'être rejetés si vous ignorez cette règle.

Les blacklists

Des listes publiques d'expéditeurs de spams existent. Si l'IP du serveur SMTP envoyant un mail est listée sur l'une de ces listes, le serveur SMTP destinataire rejettera probablement le mail.

DKIM (DomainKeys Identified Mail)

DKIM permet de chiffrer une partie de vos emails sortants par un code qui n'est déchiffrable qu'avec la clé publique présente dans votre zone DNS. Cela permet d'augmenter l'authentification des emails envoyés par votre domaine. DKIM s'inscrit sous forme d'entrée TXT dans votre zone DNS.

Activer DKIM via Plesk

Pour activer DKIM, pour votre domaine:

  • Rendez-vous dans votre Panneau de contrôle Plesk
  • Dans "Adresses email" puis "Paramètres de la messagerie"
  • Cochez "Utiliser le système anti-spam DKIM pour signer les mails sortants" et cliquez sur OK

La signature DKIM et l'entrée DNS correspondante sont alors automatiquement activées.

DMARC (Domain-based Message Authentication)

DMARC permet de choisir une action en cas de non-respect de DKIM ou de SPF.

Cette entrée DNS de type TXT permet également de définir une adresse à qui envoyer les informations de rejets de mails de votre domaine, ce qui vous fera recevoir un email de la part de tous les plus grands prestataires à qui votre domaine aura envoyé des emails. Cette norme est de plus en plus utilisée. Elle se présente sous forme d'entrée TXT dans votre zone DNS. Dans certains cas, si on vous l'impose, vous pouvez entrer une règle DMARC vide :

_DMARC TXT v=DMARC1; p=none

Une valeur plus utile serait néanmoins plutôt de ce type :

_DMARC TXT v=DMARC1; p=reject; fo=0; adkim=r; aspf=s; pct=100; ri=86400; sp=reject

Une telle valeur permet de rejeter tous les mails ne respectant pas SPF mais laisse passer en cas de souci DKIM, elle permet aussi de ne pas accepter l'envoi de mails en tant qu'un sous-domaine de votre domaine. C'est donc un gage de sécurité non négligeable pour votre domaine.

D'autres champs existent pour recevoir des rapports des mails envoyés en tant que votre domaine vers les différents prestataires de mails. Cet article vous donnera plus d'informations : https://help.returnpath.com/hc/fr/articles/222437867-Quelles-sont-les-diff%C3%A9rentes-balises-d-un-enregistrement-DMARC-