Tag: serveur SMTP

Serveur dédié : ajouter l’authentification DMARC à Postfix et BIND

4 April 202220 avril 2016 by Matt Biscay · Lecture: 9 minutes

Notre serveur de mail possède une identification SPF, Sender-ID et DKIM et est sécurisé par un certificat TLS. Nous allons aujourd’hui voir comment lui adjoindre l’authentification DMARC.

Aux origines de l’authentification des emails

Les technologies d’authentification des emails SPF et DKIM ont été développées afin de fournir une plus grande assurance sur l’identité de l’expéditeur d’un message.

L’adoption de ces technologies a augmenté régulièrement mais le problème des emails frauduleux et trompeurs n’a pu etre réglé.

Il existe une multitude d’environnements et de systèmes différents pour envoyer des emails, et on fait souvent appel à des applications tierces pour gérer les envois.

S’assurer que chaque message peut être authentifié avec SPF ou DKIM n’est pas une mince affaire étant donné que le traitement des emails se fait en temps réel.

Si le propriétaire d’un domaine envoie un groupe de message et que certains peuvent être authentifiés et d’autres non, alors les récipiendaires de ces messages sont obligés de faire la distinction entre les messages légitimes qui ne sont pas authentifiés et les messages frauduleux qui ne sont pas authentifiés non plus.

Par nature, les algorithmes de spam sont sujets aux erreurs et doivent évoluer constamment pour répondre aux nouvelles tactiques des spammeurs. Au final, certains messages frauduleux parviendront toujours à atteindre la boite de réception du destinataire final.

Le seul moyen de résoudre ces problèmes est de partager l’information entre l’expéditeur et le destinataire. Les destinataires vont fournir des informations sur leur infrastructure d’authentification des messages et les expéditeurs vont dire aux destinataires quoi faire lorsqu’un message reçu n’est pas authentifié.

En 2007, Paypal a été pionnier dans cette approche et a construit un système avec l’aide de Yahoo! Mail puis Gmail. Les résultats ont été très probants, menant à une baisse du nombre des emails frauduleux qui se faisaient passer comme venant des serveurs de Paypal acceptés par les destinataires.

DMARC : un protocole d’authentification email

DMARC, qui signifie Domain-based Message Authentication, Reporting and Conformance est un protocole d’authentification email qui se base sur les protocoles SPF et DKIM – maintenant largement déployés – en ajoutant une fonction de rapport qui permet aux expéditeurs et destinataires d’améliorer et vérifier la protection du domaine contre les emails frauduleux.

DMARC se base sur le processus d’authentification des messages entrants et aide les destinataires à déterminer si les message est “aligné” avec ce que le destinataire connaît de l’expéditeur. Sinon, DMARC inclut une manière de gérer les messages “non-alignés”.

Voici le principe de fonctionnement de DMARC :

Serveur dédié : ajouter l'authentification DMARC à Postfix et Bind9 photo

Il est important de noter que DMARC est basé à la fois sur les spécifications de DKIM (DomainKeys Identified Mail) et SPF (Sender Policy Framework) qui sont toujours en cours de développement par l’IETF.

Sommaire de la série Monter un serveur dédié de A à Z

« Serveur dédié : ajouter le domaine à la liste HSTS preload

Serveur dédié : à la recherche de l’inode perdue ou comment résoudre le problème “no space left on device” »

Postfix : résoudre l’erreur “Untrusted TLS connection established to Gmail”

8 April 202206 mai 2015 by Matt Biscay · Lecture: 2 minutes

En vérifiant les logs de mon serveur mail, je me suis aperçu que, malgré mon certificat, la connexion du serveur à un serveur sortant n’était pas entièrement chiffrée.

Voici comment remédier à ce problème.

Postfix : “untrusted connection SMTP”

Concrètement, voici la transcription du log d’une connexion SMTP dite “untrusted connection SMTP” :

postfix/cleanup: message-id=<9@mail.example.com>
opendkim: DKIM-Signature field added (s=mail, d=example.com)
postfix/qmgr: from=<user@example.com>, size=483, nrcpt=1 (queue active)
postfix/smtp: Untrusted TLS connection established to gmail-smtp-in.l.google.com[2a00:1450:4013:c01::1a]:25: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
postfix/smtp: to=<user@gmail.com>, relay=gmail-smtp-in.l.google.com[2a00:1450:4013:c01::1a]:25, delay=1.5, delays=0.12/0.06/0.55/0.73, dsn=2.0.0, status=sent (250 2.0.0 OK 1430771763 z16si1523612wjr.190 - gsmtp)
postfix/qmgr: removed</user@gmail.com></user@example.com>

Comme on peut le constater, notre connexion TLS n’est pas chiffrée de bout en bout :

Untrusted TLS connection established to gmail-smtp-in.l.google.com[2a00:1450:4013:c01::1a]:25: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)

Solution : ajouter la directive smtp_tls_CAfile

J’ai pour habitude de mettre les mêmes valeurs pour les directives smtp_* et smtpd_* mais dans ce cas précis, il faut modifier la valeur de la directive smtp_tls_CAfile.

On édite le fichier de configuration de Postfix :

nano /etc/postfix/main.cf

On modifie smtp_tls_CAfile pour pointer vers le fichier /etc/ssl/certs/ca-certificates.crt:

###
# Trusted TLS connection to gmail-smtp
# by Matt 
# https://www.skyminds.net
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
###

et on redémarre Postfix :

service postfix restart

Trusted TLS connection established

Après un envoi de test, voici ce que nous donnent les logs:

postfix/cleanup: message-id=<a@mail.example.com>
opendkim: DKIM-Signature field added (s=mail, d=example.com)
postfix/qmgr: from=<user@example.com>, size=483, nrcpt=1 (queue active)
postfix/smtp: Trusted TLS connection established to gmail-smtp-in.l.google.com[74.125.136.27]:25: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
postfix/smtp: to=<user@gmail.com>, relay=gmail-smtp-in.l.google.com[74.125.136.27]:25, delay=1.1, delays=0.12/0.07/0.31/0.58, dsn=2.0.0, status=sent (250 2.0.0 OK 1430772064 jt5si24487408wjc.48 - gsmtp)
postfix/qmgr: removed</user@gmail.com></user@example.com></a@mail.example.com>

Et voilà, connexion vers les serveurs SMTP chiffrée et validée comme trusted!

Serveur dédié : création d’un serveur mail Postfix (sécurisé avec Saslauthd et certificat SSL) et Courier (accès POP et IMAP) utilisant une base MySQL d’utilisateurs/domaines virtuels

9 April 202217 mars 2011 by Matt Biscay · Lecture: 17 minutes

Aujourd’hui, nous voyons comment créer un serveur mail sécurisé et qui tient bien la route. Comme je suis seul utilisateur du serveur, je ne voyais pas trop l’intérêt de créer des comptes utilisateurs sur le serveur juste pour pouvoir bénéficier d’un serveur mail.

J’ai donc opté pour la solution suivante : un serveur mail Postfix (sécurisé avec Saslauthd et certificat SSL) et un serveur Courier (accès POP et IMAP) qui utilisent MySQL (utilisateurs et domaines virtuels) pour la redirection des messages des utilsateurs/domaines.

Le tutoriel est certainement le plus long de la série, j’estime que cela prend à peu près 50 minutes à compléter (en 15 étapes!). Attention au niveau des copier/coller, une simple erreur peut vous faire perdre pas mal de temps !

Etape 1 : configurer le hostname

Le hostname est le nom du serveur en général. Mon domaine est skyminds.net donc mon serveur s’appelle mail.skyminds.net

Il est également important que ce nom soit présent dans la configuration bind du serveur.

Pour connaitre le nom de votre machine, tapez :

hostname -f

Pour le modifiez, il faut éditer /etc/hostname :

nano /etc/hostname

Remplacez ce qui s’y trouve avec le nom de votre serveur. J’y mets ‘mail.skyminds.net’.

Ensuite, éditez /etc/hosts:

nano /etc/hosts

On ne touche pas à la première ligne mais on ajoute l’adresse IP du serveur suivie de notre nom de machine :

127.0.0.1       localhost.localdomain localhost
xxx.xxx.xxx.xxx  mail.skyminds.net

Il ne vous reste plus qu’à rebooter le serveur pour que les modifications soient prises en compte :

/sbin/reboot

Vérifiez bien que le nouveau nom a bien changé :

hostname -f

J’obtiens bien :

mail.skyminds.net

Si vous obtenez une erreur du style “name or service not found”, vérifiez que les enregistrements DNS du serveur sont bien corrects.

Sommaire de la série Monter un serveur dédié de A à Z

« Serveur dédié : sécurisation de la couche TCP/IP

Serveur dédié : sécuriser Apache 2 avec ModSecurity »

Migration de serveur : Kimsufi 250G

4 August 202112 février 2011 by Matt Biscay · Lecture: 6 minutes

Aujourd’hui, je vous donne les quelques news techniques du site.

Serveur Kimsufi 500G

Cela fait presque un an que SkyMinds.Net tourne sur un serveur dédié hébergé chez OVH. Le serveur était un Kimsufi avec 500 Go de disque dur.

Quelques jours seulement après le transfert du site, OVH annonce le Kimsufi avec 250 Go mais… à moitié prix ! Et on ne peut rendre un serveur Kimsufi pour un autre, il s’agit de deux achats séparés.

Au niveau des performances, je dirai que mon Kimsufi 500G n’était pas terrible : il était constamment surchargé et j’avais l’impression de devoir relancer les services régulièrement pour assurer la disponibilité du service. Pas cool du tout.

SkyMinds.Net hébergé chez OVH

10 October 202115 mars 2010 by Matt Biscay · Lecture: 3 minutes

Vous ne l’avez peut-être pas remarqué mais le site a été transféré sur un nouveau serveur : changement d’hébergeur donc. Le site quitte l’Angleterre pour venir s’installer en France, chez OVH.

D’ailleurs, si vous pouvez lire cet article, cela veut dire que la propagation DNS est terminée et que je n’ai pas fait trop de bêtises.

Le serveur

Le serveur est un serveur dédié à base de Celeron 1.2 Ghz avec 2 Go de RAM donc cela devrait changer d’un hébergement mutualisé avec des centaines de sites hébergés sur le même serveur.

Là, je suis tout seul : il y a le site bien sûr mais aussi tous les services connexes tels que le serveur FTP, le serveur de mail, le serveur DNS etc.

Tout cela tourne sur la même machine donc finalement, ce qui sur le papier a l’air très bien l’est un peu moins une fois que tout est configuré.

Rapatrier gratuitement ses mails Hotmail ou Live sur son compte Gmail

24 April 202213 janvier 2009 by Matt Biscay · Lecture: 2 minutes

C’est officiel : Microsoft vient de rendre l’accès au serveur POP de Live/Hotmail gratuit. Le service était payant auparavant et coûtait 19 dollars par an si je ne m’abuse.

Le hic, c’est que tous les concurrents proposaient cela gratuitement. Microsoft a donc dû s’adapter afin d’éviter l’hémorragie de ses utilisateurs vers d’autres services comme Yahoo! Mail ou Gmail.

Il n’y a donc plus besoin de l’astuce précédente tout est simplifié !