Une session SMTP entre deux serveurs de messagerie peut être chiffrée, mais seulement si les deux extrémités la prennent en charge et si les deux extrémités choisissent de l'utiliser . Donc, si vous envoyez des e-mails de Gmail à example.net, Google ne pourrait chiffrer que si example.net était prêt et disposé. Pour cette raison, vous ne pouvez pas faire confiance au courrier électronique, même modérément sécurisé au niveau de la couche de transport. (La seule méthode sûre de bout en bout consiste à crypter vos e-mails à l'aide de S / MIME ou PGP, mais les personnes avec lesquelles vous échangez des e-mails doivent également être à bord ... tout comme les serveurs de messagerie).
Quant à savoir si les trois grands exécutent des STARTTLS opportunistes, je n'en ai vu aucune preuve, mais je passe moins de temps à lire les journaux de mon serveur de messagerie qu'auparavant. Et s'ils le sont, ils ne représentent toujours que la moitié de chaque connexion SMTP qu'ils établissent, et ne peuvent pas garantir l'utilisation du chiffrement.
Mise à jour:
Je viens de tester les hôtes MX pour gmail .com, yahoo.com et hotmail.com. Seul gmail fait la publicité de STARTTLS, c'est-à-dire que seul gmail serait prêt à chiffrer la session SMTP si l'autre partie le souhaitait.
J'ai testé gmail sortant en envoyant du courrier à un serveur que je possède et en surveillant le fil; Google profite en effet de STARTTLS s'il est proposé et crypte la transaction SMTP lorsqu'un utilisateur gmail envoie du courrier. Props to Google.
En ce qui concerne le cryptage des e-mails: Google 1, Yahoo 0, Microsoft 0.
Selon les commentaires ci-dessous, si vous le souhaitez pour les tester vous-même, c'est très simple:
- Déterminez les hôtes MX (Mail eXchangers) pour le domaine
- Telnet vers le port 25 sur l'un d'eux
- Tapez "ehlo yourhostname.domain.com"
- Si vous ne voyez pas "250-STARTTLS" comme l'une des réponses, ils ne prennent pas en charge le chiffrement opportuniste.
ol> Comme ceci:
$ host -t mx yahoo.comyahoo.com le courrier est traité par 1 mta5.am0.yahoodns.net.yahoo.com le courrier est traité par 1 mta7 Le courrier .am0.yahoodns.net.yahoo.com est géré par 1 mta6.am0.yahoodns.net.
$ telnet mta5.am0.yahoodns.net 25Essai 66.196.118.35 ... Connecté à mta5.am0.yahoodns.net.Le caractère d'échappement est '^]'. 220 mta1315.mail.bf1.yahoo.com Le service ESMTP YSmtpProxy est prêt pour mon hôte. linode.com250-mta1315.mail.bf1.yahoo.com250-8BITMIME250-SIZE 41943040250 PIPELININGquit221 mta1315.mail.bf1.yahoo.comConnexion fermée par un hôte étranger. $
En remarque, Yahoo fermera la connexion si vous n'effectuez pas d'ehlo tout de suite. J'ai dû couper & coller mon ehlo car la saisie a pris trop de temps.
PLUS DE MISE À JOUR:
Depuis janvier 2014, Yahoo est en train de chiffrer - Je viens de tester (comme ci-dessus) et de vérifier. Cependant, The Register et Computerworld signalent que les subtilités de la configuration SSL (telles que Perfect Forward Secrecy) laissent beaucoup à désirer comme implémenté par Yahoo.
MISE À JOUR ENCORE PLUS MORTE:
Google inclut désormais les données de chiffrement SMTP dans sa section Transparency Report Safer Email. Ils partagent leurs données sur les autres personnes souhaitant chiffrer, et vous pouvez consulter les premiers chiffres et interroger des domaines individuels.
Addendum:
@SlashNetwork indique qu'il est possible de configurer un serveur de messagerie pour exiger que TLS soit négocié avant d'échanger du courrier. C'est vrai, mais pour citer la documentation de Postfix:
Vous pouvez FAIRE APPLIQUER l'utilisation de TLS, de sorte que le serveur SMTP de Postfix annonce STARTTLS et n'accepte aucun courrier sans TLS chiffrement, en définissant "smtpd_tls_security_level = encrypt". Selon RFC 2487, cela NE DOIT PAS être appliqué dans le cas d'un serveur SMTP Postfix référencé publiquement. Cette option est désactivée par défaut et ne devrait être utilisée que rarement.
Maintenant, le monde est plein d'implémentations qui violent les RFC, mais ce genre de chose - par exemple, quelque chose qui peut briser les fonctionnalités requises de routine comme l'acceptation des rebonds et du courrier pour le postmaster - est probablement plus susceptible d'avoir des conséquences négatives.
Une meilleure solution que les passerelles de messagerie autorisent souvent est l'imposition de exigences TLS sur la base d'une politique par domaine. Par exemple, il est généralement possible de dire «Exiger TLS avec un certificat valide signé par Entrust lorsque vous parlez à example.com». Ceci est généralement mis en œuvre entre des organisations qui font partie de la même société mère mais qui ont une infrastructure différente (pensez: acquisitions) ou des organisations ayant une relation commerciale (pensez: ACME, Inc., et leur société de centre d'appels de support externalisé). Cela présente l'avantage de garantir que les sous-ensembles spécifiques de courrier qui vous intéressent soient chiffrés, mais ne rompt pas l'architecture ouverte (acceptée par n'importe qui par défaut) de la messagerie SMTP.
Addendum ++
Google a annoncé que gmail transmettra des informations sur la sécurité si le chemin de la messagerie vers le lecteur. Donc, ces étapes de cryptage en coulisses seront un peu plus portées à la connaissance de l'utilisateur.
(Probablement ne se soucie toujours pas de la provenance du certificat; juste un indicateur de cryptage des bits) .