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:

1. Déterminez les hôtes MX (Mail eXchangers) pour le domaine
2. Telnet vers le port 25 sur l'un d'eux
3. Tapez "ehlo yourhostname.domain.com"
4. 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) .

Il y a trois points dans la chaîne que vous devez prendre en compte: le transport entre les serveurs de messagerie (par exemple entre Google et example.org), le transport entre les serveurs de messagerie et les clients, et les serveurs de messagerie eux-mêmes.

Trafic entre les serveurs de messagerie peuvent ou non être cryptés; vous ne devriez pas vous y fier, et AFAIK, il n'y a aucun moyen de l'appliquer à partir du client.

Le trafic entre les clients et les serveurs de messagerie peut ou non être chiffré; si vous vous connectez via SSL (soit via une interface Web ou SMTP), votre extrémité de chaîne est sécurisée, mais vous ne pouvez rien dire sur le destinataire. Inversement, si vous êtes le destinataire, vous pouvez récupérer le courrier en toute sécurité, mais si l'expéditeur (ou n'importe qui dans le CC / Cci) ne fait pas la même chose, alors il y a votre fuite.

Et enfin, il y a les serveurs de messagerie eux-mêmes. Si quelqu'un les pirate, ou si des ingénieurs sociaux s'y frayent un chemin, et que le serveur de messagerie stocke le contenu non chiffré, alors vous n'avez pas de chance.

TL; DR: À moins que vous ne contrôliez toute la chaîne (les deux clients, et tous les serveurs de messagerie impliqués), ce qui n'est pratiquement jamais le cas, la seule façon d'envoyer des e-mails avec une sécurité fiable est de crypter et de décrypter localement, en utilisant quelque chose comme PGP.

Il y a deux questions différentes ici:

1. Le système de messagerie autorise-t-il l'envoi d'e-mails via un canal crypté et l'envoi d'e-mails via un canal crypté lorsque le serveur de messagerie du destinataire le prend en charge.

   / li>

2. Le système de messagerie crypte-t-il le contenu d'une boîte aux lettres lors de son affichage au propriétaire?

gownfawr addresses (1) bien.

Gmail crypte par défaut pour (2) donc lors de la visualisation de votre courrier, par défaut, cela se fait via HTTPS, donc un snooper ne pourra pas observer gmail envoyer le courrier à votre navigateur. Je crois que les autres n'ont pas encore suivi la suite. (Divulgation complète, je travaille pour Google).

Gmail est configuré pour utiliser le paramètre "Toujours utiliser https " par défaut, ...

"Rendre votre messagerie Web plus sécurisée" contient des instructions pour éviter les lectures en texte brut d'une boîte aux lettres pour un certain nombre de grands fournisseurs de messagerie Web, mais je ne peux pas garantir qu'il soit à la hauteur de - date.

Vous pouvez tester par vous-même en utilisant les sites Web mentionnés dans Tester la configuration STARTTLS du serveur SMTP. Assurez-vous de tester à la fois la réception et l'envoi.