Protocole de transfert de courrier simple

Le protocole SMTP ( Simple Mail Transfer Protocol ) est un protocole de communication standard Internet pour la transmission de courrier électronique . Les serveurs de messagerie et autres agents de transfert de messages utilisent SMTP pour envoyer et recevoir des messages électroniques. Les clients de messagerie au niveau de l’utilisateur utilisent généralement SMTP uniquement pour envoyer des messages à un serveur de messagerie pour le relais, et soumettent généralement les e-mails sortants au serveur de messagerie sur le port 587 ou 465 selon RFC 8314 . Pour récupérer les messages, IMAP (qui a remplacé l’ancien POP3 ) est standard, mais les serveurs propriétaires implémentent aussi souvent des protocoles propriétaires, par exemple, Exchange ActiveSync .

Les origines de SMTP ont commencé en 1980, en s’appuyant sur des concepts mis en œuvre sur l’ ARPANET depuis 1971. Il a été mis à jour, modifié et étendu à plusieurs reprises. La version du protocole couramment utilisée aujourd’hui a une structure extensible avec diverses extensions pour l’ authentification , le chiffrement , le transfert de données binaires et les adresses e-mail internationalisées . Les serveurs SMTP utilisent généralement le protocole de contrôle de transmission sur le port numéro 25 (pour le texte en clair) et 587 (pour les communications cryptées).

Histoire

Prédécesseurs de SMTP

Diverses formes de messagerie électronique individuelle ont été utilisées dans les années 1960. Les utilisateurs communiquaient à l’aide de systèmes développés pour des ordinateurs centraux spécifiques . Au fur et à mesure que de plus en plus d’ordinateurs étaient interconnectés, en particulier dans l’ ARPANET du gouvernement américain , des normes ont été développées pour permettre l’échange de messages entre différents systèmes d’exploitation. SMTP est né de ces normes développées dans les années 1970.

Le courrier sur l’ARPANET remonte à 1971 : le protocole de boîte aux lettres, qui n’a pas été implémenté, ^[1] mais est discuté dans la RFC 196 ; et le programme SNDMSG , que Ray Tomlinson de BBN a adapté cette année-là pour envoyer des messages sur deux ordinateurs sur l’ARPANET. ^{[2] [3] [4]} Une autre proposition pour un protocole de messagerie a été faite dans la RFC 524 en juin 1973, ^[5] qui n’a pas été mise en œuvre. ^[6]

L’utilisation du protocole de transfert de fichiers (FTP) pour le “courrier réseau” sur l’ARPANET a été proposée dans la RFC 469 en mars 1973 ^. Un cadre pour le « courrier électronique » utilisant des serveurs de messagerie FTP a été développé. ^[8]

SMTP d’origine

En 1980, Jon Postel et Suzanne Sluizer ont publié la RFC 772 qui proposait le protocole de transfert de courrier en remplacement de l’utilisation du FTP pour le courrier. La RFC 780 de mai 1981 a supprimé toutes les références à FTP et alloué le port 57 pour TCP et UDP ^{[ citation nécessaire ]} , une allocation qui a depuis été supprimée par l’ IANA . En novembre 1981, Postel a publié la RFC 788 “Simple Mail Transfer Protocol”.

La norme SMTP a été développée à peu près au même moment que Usenet , un réseau de communication un-à-plusieurs avec quelques similitudes. ^{[ citation nécessaire ]}

SMTP est devenu largement utilisé au début des années 1980. À l’époque, il s’agissait d’un complément au programme de copie Unix vers Unix (UUCP), qui était mieux adapté pour gérer les transferts d’e-mails entre des machines connectées par intermittence. SMTP, en revanche, fonctionne mieux lorsque les machines d’envoi et de réception sont connectées au réseau en permanence. Les deux utilisaient un mécanisme de stockage et de retransmission et sont des exemples de technologie push . Bien que les newsgroups d’ Usenet aient toujours été propagés avec UUCP entre les serveurs, ^[9] UUCP en tant que transport de courrier a pratiquement disparu ^[10] avec les ” bang paths ” qu’il utilisait comme en-têtes de routage des messages. ^[11]

Sendmail , publié avec 4.1cBSD en 1983, a été l’un des premiers agents de transfert de courrier à implémenter SMTP. ^[12] Au fil du temps, alors que BSD Unix est devenu le système d’exploitation le plus populaire sur Internet, Sendmail est devenu le MTA (Agent de transfert de courrier) le plus courant. ^[13]

Le protocole SMTP d’origine ne prenait en charge que les communications textuelles ASCII 7 bits non authentifiées et non cryptées, sensibles aux attaques triviales de l’homme du milieu , à l’ usurpation d’ identité et au spam , et nécessitant que toutes les données binaires soient codées en texte lisible avant la transmission. En raison de l’absence d’un mécanisme d’authentification approprié, de par sa conception, chaque serveur SMTP était un relais de messagerie ouvert . L’ Internet Mail Consortium (IMC) a rapporté que 55% des serveurs de messagerie étaient des relais ouverts en 1998, ^[14] mais moins de 1% en 2002. ^[15] En raison des problèmes de spam, la plupart des fournisseurs de messagerie bloquent les relais ouverts, ^[16]rendant le SMTP d’origine essentiellement impraticable pour une utilisation générale sur Internet.

SMTP moderne

En novembre 1995, la RFC 1869 a défini le protocole ESMTP (Extended Simple Mail Transfer Protocol), qui a établi une structure générale pour toutes les extensions existantes et futures visant à ajouter les fonctionnalités manquantes du SMTP d’origine. ESMTP définit des moyens cohérents et gérables par lesquels les clients et serveurs ESMTP peuvent être identifiés et les serveurs peuvent indiquer les extensions prises en charge.

La soumission de messages ( RFC 2476 ) et SMTP-AUTH ( RFC 2554 ) ont été introduites en 1998 et 1999, toutes deux décrivant les nouvelles tendances en matière de livraison de courrier électronique. À l’origine, les serveurs SMTP étaient généralement internes à une organisation, recevant le courrier de l’organisation de l’extérieur et relayant les messages de l’organisation vers l’extérieur . Mais au fil du temps, les serveurs SMTP (agents de transfert de courrier) étendaient en pratique leurs rôles pour devenir des agents de soumission de messages pour les agents utilisateurs Mail , dont certains relayaient désormais le courrier de l’extérieur . d’une organisation. (par exemple, un dirigeant d’entreprise souhaite envoyer des e-mails lors d’un voyage en utilisant le serveur SMTP de l’entreprise.) Ce problème, conséquence de l’expansion rapide et de la popularité du World Wide Web , signifiait que SMTP devait inclure des règles et des méthodes spécifiques pour relayer le courrier et authentifier les utilisateurs pour éviter les abus tels que le relais d’e-mails non sollicités ( spam ). Travailler sur la soumission de messages ( RFC 2476 ) a été lancé à l’origine parce que les serveurs de messagerie populaires réécrivaient souvent le courrier dans le but de résoudre des problèmes, par exemple en ajoutant un nom de domaine à une adresse non qualifiée. Ce comportement est utile lorsque le message en cours de correction est une soumission initiale, mais dangereux et nuisible lorsque le message provient d’ailleurs et est relayé. Séparer proprement le courrier en soumission et relais était considéré comme un moyen de permettre et d’encourager les soumissions de réécriture tout en interdisant le relais de réécriture. Au fur et à mesure que le spam devenait plus répandu, il était également considéré comme un moyen de fournir une autorisation pour l’envoi de courrier depuis une organisation, ainsi qu’une traçabilité. Cette séparation du relais et de la soumission est rapidement devenue la base des pratiques modernes de sécurité des e-mails.

Comme ce protocole a commencé purement basé sur du texte ASCII , il ne gérait pas bien les fichiers binaires ou les caractères dans de nombreuses langues autres que l’anglais. Des normes telles que Multipurpose Internet Mail Extensions ( MIME ) ont été développées pour coder les fichiers binaires à transférer via SMTP. Les agents de transfert de courrier (MTA) développés après Sendmail avaient également tendance à être implémentés 8 bits propres , de sorte que la stratégie alternative “juste envoyer huit” pouvait être utilisée pour transmettre des données textuelles arbitraires (dans n’importe quel codage de caractères de type ASCII 8 bits) via SMTP. Mojibake était toujours un problème en raison des différents mappages de jeux de caractères entre les fournisseurs, bien que les adresses e-mail elles-mêmes n’autorisaient toujours que l’ASCII .. Aujourd’hui, les MTA 8 bits propres ont tendance à prendre en charge l’extension 8BITMIME, permettant à certains fichiers binaires d’être transmis presque aussi facilement que du texte brut (les limites de longueur de ligne et les valeurs d’octet autorisées s’appliquent toujours, de sorte que le codage MIME est nécessaire pour la plupart des non-texte données et certains formats de texte). En 2012, l’ SMTPUTF8extension a été créée pour prendre en charge le texte UTF-8 , permettant le contenu international et les adresses dans des scripts non latins comme le cyrillique ou le chinois .

De nombreuses personnes ont contribué aux principales spécifications SMTP, parmi lesquelles Jon Postel , Eric Allman , Dave Crocker, Ned Freed , Randall Gellens, John Klensin et Keith Moore .

Modèle de traitement du courrier

Les flèches bleues illustrent la mise en œuvre des variantes SMTP

Le courrier électronique est soumis par un client de messagerie ( agent d’utilisateur de messagerie , MUA) à un serveur de messagerie (agent de soumission de courrier , MSA) à l’aide de SMTP sur le port TCP 587. La plupart des fournisseurs de boîtes aux lettres autorisent toujours la soumission sur le port traditionnel 25. Le MSA distribue le courrier à son Agent de transfert de courrier (Agent de transfert de courrier , MTA). Souvent, ces deux agents sont des instances du même logiciel lancé avec des options différentes sur la même machine. Le traitement local peut être effectué soit sur une seule machine, soit réparti sur plusieurs machines ; les processus d’agent de messagerie sur une machine peuvent partager des fichiers, mais si le traitement s’effectue sur plusieurs machines, ils transfèrent les messages entre eux à l’aide de SMTP, où chaque machine est configurée pour utiliser la machine suivante commehôte intelligent . Chaque processus est un MTA (un serveur SMTP) à part entière.

Le MTA limite utilise DNS pour rechercher l’enregistrement MX (échangeur de messagerie) du domaine du destinataire (la partie de l’ adresse e -mail à droite de @). L’enregistrement MX contient le nom du MTA cible. En fonction de l’hôte cible et d’autres facteurs, le MTA expéditeur sélectionne un serveur destinataire et s’y connecte pour terminer l’échange de courrier.

Le transfert de messages peut se produire dans une seule connexion entre deux MTA, ou dans une série de sauts via des systèmes intermédiaires. Un serveur SMTP de réception peut être la destination ultime, un “relais” intermédiaire (c’est-à-dire qu’il stocke et transmet le message) ou une “passerelle” (c’est-à-dire qu’il peut transférer le message en utilisant un protocole autre que SMTP). Selon la section 2.1 de la RFC 5321 , chaque saut est un transfert formel de responsabilité pour le message, dans lequel le serveur de réception doit soit livrer le message, soit signaler correctement l’échec de le faire.

Une fois que le saut final accepte le message entrant, il le remet à un agent de distribution de courrier (MDA) pour une livraison locale. Un MDA enregistre les messages dans le format de boîte aux lettres approprié. Comme pour l’envoi, cette réception peut être effectuée à l’aide d’un ou de plusieurs ordinateurs, mais dans le schéma ci-dessus, le MDA est représenté comme une boîte près de la boîte de l’échangeur de courrier. Un MDA peut livrer des messages directement au stockage ou les transmettre sur un réseau à l’aide de SMTP ou d’un autre protocole tel que le protocole de transfert de courrier local (LMTP), un dérivé de SMTP conçu à cet effet.

Une fois remis au serveur de messagerie local, le courrier est stocké pour être récupéré par lots par des clients de messagerie authentifiés (MUA). Le courrier est récupéré par les applications de l’utilisateur final, appelées clients de messagerie, à l’aide du protocole Internet Message Access Protocol (IMAP), un protocole qui facilite l’accès au courrier et gère le courrier stocké, ou le protocole Post Office (POP) qui utilise généralement le courrier mbox traditionnel. format de fichier ou un système propriétaire tel que Microsoft Exchange/Outlook ou Lotus Notes / Domino . Les clients de messagerie Web peuvent utiliser l’une ou l’autre méthode, mais le protocole de récupération n’est souvent pas une norme formelle.

SMTP définit le transport des messages , pas le contenu du message . Ainsi, il définit l’ enveloppe du courrier et ses paramètres, tels que l’ expéditeur de l’enveloppe , mais pas l’en-tête (sauf les informations de trace ) ni le corps du message lui-même. STD 10 et RFC 5321 définissent SMTP (l’enveloppe), tandis que STD 11 et RFC 5322 définissent le message (en-tête et corps), formellement appelé Internet Message Format .

Présentation du protocole

SMTP est un protocole texte orienté connexion dans lequel un expéditeur de courrier communique avec un destinataire de courrier en émettant des chaînes de commande et en fournissant les données nécessaires sur un canal de flux de données ordonné fiable, généralement une connexion TCP ( Transmission Control Protocol ). Une session SMTP se compose de commandes émises par un client SMTP (l’ agent initiateur , l’expéditeur ou l’émetteur) et les réponses correspondantes du serveur SMTP (l’agent d’écoute ou le récepteur) afin que la session soit ouverte et que les paramètres de session soient échangés. Une session peut inclure zéro ou plusieurs transactions SMTP. Une transaction SMTPse compose de trois séquences de commande/réponse :

1. Commande MAIL , pour établir l’adresse de retour, également appelée chemin de retour, ^[17] chemin inverse, ^[18] adresse de rebond , mfrom ou expéditeur de l’enveloppe.
2. Commande RCPT , pour établir un destinataire du message. Cette commande peut être émise plusieurs fois, une pour chaque destinataire. Ces adresses font également partie de l’enveloppe.
3. DATA pour signaler le début du texte du message ; le contenu du message, par opposition à son enveloppe. Il se compose d’un en-tête de message et d’un corps de message séparés par une ligne vide. DATA est en fait un groupe de commandes, et le serveur répond deux fois : une fois à la commande DATA elle-même, pour reconnaître qu’il est prêt à recevoir le texte, et la deuxième fois après la séquence de fin de données, pour accepter ou rejeter l’intégralité du message.

Outre la réponse intermédiaire pour DATA, la réponse de chaque serveur peut être positive (codes de réponse 2xx) ou négative. Les réponses négatives peuvent être permanentes (codes 5xx) ou transitoires (codes 4xx). Un rejet est un échec permanent et le client doit envoyer un message de rebond au serveur à partir duquel il l’a reçu. Une baisse est une réponse positive suivie d’un rejet de message plutôt que d’une livraison.

L’hôte initiateur, le client SMTP, peut être soit le client de messagerie d’un utilisateur final , fonctionnellement identifié en tant qu’Agent utilisateur de messagerie (MUA), soit l’ agent de transfert de messagerie (MTA) d’un serveur relais , c’est-à-dire un serveur SMTP agissant en tant que client SMTP. , dans la session concernée, afin de relayer le courrier. Des serveurs SMTP entièrement capables maintiennent des files d’attente de messages pour réessayer les transmissions de messages qui ont entraîné des échecs transitoires.

Un MUA connaît le serveur SMTP de courrier sortant à partir de sa configuration. Un serveur relais détermine généralement le serveur auquel se connecter en recherchant l’ enregistrement de ressource DNS MX (Mail eXchange) pour le nom de domaine de chaque destinataire . Si aucun enregistrement MX n’est trouvé, un serveur de relais conforme (tous ne le sont pas) recherche à la place l’ enregistrement A . Les serveurs relais peuvent également être configurés pour utiliser un hôte intelligent . Un serveur relais initie une connexion TCP vers le serveur sur le « port connu » pour SMTP : le port 25, ou pour se connecter à un MSA, le port 587. La principale différence entre un MTA et un MSA est que la connexion à un MSA nécessiteAuthentification SMTP .

SMTP vs récupération de courrier

SMTP est un protocole de livraison uniquement. En utilisation normale, le courrier est “poussé” vers un serveur de messagerie de destination (ou un serveur de messagerie de saut suivant) à mesure qu’il arrive. Le courrier est acheminé en fonction du serveur de destination, et non des utilisateurs individuels auxquels il est adressé. D’autres protocoles, tels que le protocole Post Office (POP) et le protocole d’accès aux messages Internet (IMAP) sont spécifiquement conçus pour être utilisés par des utilisateurs individuels récupérant des messages et gérant des boîtes aux lettres . Pour permettre à un serveur de messagerie connecté par intermittence d’ extraire des messages d’un serveur distant à la demande, SMTP dispose d’une fonctionnalité permettant de lancer le traitement de la file d’attente de messagerie sur un serveur distant (voir Démarrage de la file d’attente de messages à distanceau dessous de). POP et IMAP ne sont pas des protocoles adaptés pour relayer le courrier par des machines connectées par intermittence ; ils sont conçus pour fonctionner après la livraison finale, lorsque les informations essentielles au bon fonctionnement du relais de messagerie (“l’enveloppe de courrier”) ont été supprimées.

Démarrage de la file d’attente des messages à distance

Le démarrage à distance de la file d’attente des messages permet à un hôte distant de démarrer le traitement de la file d’attente des messages sur un serveur afin qu’il puisse recevoir les messages qui lui sont destinés en envoyant une commande correspondante. La TURNcommande d’origine a été jugée non sécurisée et a été étendue dans RFC 1985 avec la commande qui fonctionne de manière plus sécurisée en utilisant une méthode d’ authentification basée sur les informations du système de noms de domaine . ^[19] ETRN

Serveur SMTP de courrier sortant

Un client de messagerie doit connaître l’adresse IP de son serveur SMTP initial et cela doit être indiqué dans le cadre de sa configuration (généralement sous forme de nom DNS ). Ce serveur délivrera les messages sortants au nom de l’utilisateur.

Restrictions d’accès au serveur de courrier sortant

Les administrateurs de serveur doivent imposer un certain contrôle sur les clients qui peuvent utiliser le serveur. Cela leur permet de faire face aux abus, par exemple les spams . Deux solutions sont couramment utilisées :

• Dans le passé, de nombreux systèmes imposaient des restrictions d’utilisation en fonction de l’ emplacement du client, n’autorisant l’utilisation que par les clients dont l’adresse IP est celle que les administrateurs du serveur contrôlent. L’utilisation à partir de toute autre adresse IP cliente est interdite.
• Les serveurs SMTP modernes offrent généralement un système alternatif qui nécessite l’ authentification des clients par des informations d’identification avant d’autoriser l’accès.

Restreindre l’accès par emplacement

Dans ce système, le serveur SMTP d’un FAI n’autorisera pas l’accès aux utilisateurs qui se trouvent à l’extérieur du réseau du FAI. Plus précisément, le serveur peut n’autoriser l’accès qu’aux utilisateurs disposant d’une adresse IP fournie par le FAI, ce qui revient à exiger qu’ils soient connectés à Internet via ce même FAI. Un utilisateur mobile peut souvent être sur un réseau autre que celui de son FAI normal, et constatera alors que l’envoi d’e-mails échoue car le choix de serveur SMTP configuré n’est plus accessible.

Ce système a plusieurs variantes. Par exemple, le serveur SMTP d’une organisation peut uniquement fournir un service aux utilisateurs sur le même réseau, en appliquant cela par un pare-feu pour bloquer l’accès des utilisateurs sur l’Internet plus large. Ou le serveur peut effectuer des vérifications de plage sur l’adresse IP du client. Ces méthodes étaient généralement utilisées par les entreprises et les institutions telles que les universités qui fournissaient un serveur SMTP pour le courrier sortant uniquement pour une utilisation interne au sein de l’organisation. Cependant, la plupart de ces organismes utilisent désormais des méthodes d’authentification client, comme décrit ci-dessous.

Lorsqu’un utilisateur est mobile et peut utiliser différents FAI pour se connecter à Internet, ce type de restriction d’utilisation est onéreux et la modification de l’adresse du serveur SMTP de messagerie sortante configurée n’est pas pratique. Il est hautement souhaitable de pouvoir utiliser les informations de configuration du client de messagerie qui n’ont pas besoin d’être modifiées.

Authentification des clients

Les serveurs SMTP modernes exigent généralement l’ authentification des clients par des informations d’identification avant d’autoriser l’accès, plutôt que de restreindre l’accès par emplacement comme décrit précédemment. Ce système plus flexible est convivial pour les utilisateurs mobiles et leur permet d’avoir un choix fixe de serveur SMTP sortant configuré. L’authentification SMTP , souvent abrégée SMTP AUTH, est une extension du SMTP permettant de se connecter à l’aide d’un mécanisme d’authentification.

Ports

La communication entre les serveurs de messagerie utilise généralement le port TCP standard 25 désigné pour SMTP.

Cependant , les clients de messagerie ne l’utilisent généralement pas, mais utilisent plutôt des ports de “soumission” spécifiques. Les services de messagerie acceptent généralement la soumission d’e-mails par les clients sur l’un des éléments suivants :

• 587 (Soumission), tel que formalisé dans la RFC 6409 (anciennement RFC 2476 )
• 465 Ce port a été déprécié après la RFC 2487 , jusqu’à la publication de la RFC 8314 .

Le port 2525 et d’autres peuvent être utilisés par certains fournisseurs individuels, mais n’ont jamais été officiellement pris en charge.

De nombreux fournisseurs de services Internet bloquent désormais tout le trafic sortant du port 25 de leurs clients. Principalement comme mesure anti-spam, ^[20] mais aussi pour remédier au coût plus élevé qu’ils ont en le laissant ouvert, peut-être en facturant plus aux quelques clients qui en ont besoin.

Exemple de transport SMTP

Un exemple typique d’envoi d’un message via SMTP à deux boîtes aux lettres ( alice et theboss ) situées dans le même domaine de messagerie ( example.com ) est reproduit dans l’échange de session suivant. (Dans cet exemple, les parties de conversation sont préfixées par S: et C: , pour server et client , respectivement ; ces étiquettes ne font pas partie de l’échange.)

Une fois que l’expéditeur du message (client SMTP) a établi un canal de communication fiable avec le destinataire du message (serveur SMTP), la session est ouverte par un message d’accueil du serveur, contenant généralement son nom de domaine complet (FQDN), dans ce cas smtp.example .com . Le client initie son dialogue en répondant par une HELOcommande s’identifiant dans le paramètre de la commande avec son FQDN (ou un littéral d’adresse si aucun n’est disponible). ^[21]

S : 220 smtp.example.com ESMTP Postfix C : relais HELO.exemple.org S : 250 Bonjour relay.example.org, je suis ravi de vous rencontrer C : COURRIER DE :<bob@example.org> S : 250 OK C : RCPT À : <alice@example.com> S : 250 OK C : RCPT À :<theboss@example.com> S : 250 OK C : DONNÉES S : 354 Données de fin avec <CR><LF>.<CR><LF> C : De : “Bob Example” <bob@example.org> C : À : “Exemple d’Alice” <alice@example.com> C : Cc : theboss@example.com C : Date : mar. 15 janv. 2008 16:02:43 -0500 C : Objet : Message de test C : C : Bonjour Alice. C : Il s’agit d’un message de test avec 5 champs d’en-tête et 4 lignes dans le corps du message. C : Votre ami, C : Bob C : . S : 250 Ok : mis en file d’attente en tant que 12345 C : QUITTER S : 221 au revoir {Le serveur ferme la connexion}

Le client informe le destinataire de l’adresse e-mail d’origine du message dans une MAIL FROMcommande. Il s’agit également de l’adresse de retour ou de rebond au cas où le message ne pourrait pas être livré. Dans cet exemple, le message électronique est envoyé à deux boîtes aux lettres sur le même serveur SMTP : une pour chaque destinataire répertorié dans les champs d’en-tête To:et . Cc:La commande SMTP correspondante est RCPT TO. Chaque réception et exécution réussie d’une commande est acquittée par le serveur avec un code de résultat et un message de réponse (par exemple, 250 Ok).

La transmission du corps du message mail est initiée par une DATAcommande après quoi elle est transmise textuellement ligne par ligne et se termine par une séquence de fin de données. Cette séquence se compose d’un retour à la ligne ( <CR><LF>), d’un seul point ( .), suivi d’un autre retour à la ligne ( <CR><LF>). Puisqu’un corps de message peut contenir une ligne avec juste un point dans le texte, le client envoie deux points chaque fois qu’une ligne commence par un point ; en conséquence, le serveur remplace chaque séquence de deux points en début de ligne par un seul. Une telle méthode d’échappement est appelée dot-stuffing .

La réponse positive du serveur à la fin des données, comme illustré, implique que le serveur a pris la responsabilité de délivrer le message. Un message peut être doublé s’il y a une panne de communication à ce moment, par exemple en raison d’une coupure de courant : Tant que l’expéditeur n’a pas reçu cette 250 Okréponse, il doit supposer que le message n’a pas été livré. D’autre part, une fois que le destinataire a décidé d’accepter le message, il doit supposer que le message lui a été remis. Ainsi, pendant ce laps de temps, les deux agents disposent de copies actives du message qu’ils vont tenter de délivrer. ^[22]La probabilité qu’un échec de communication se produise exactement à cette étape est directement proportionnelle à la quantité de filtrage que le serveur effectue sur le corps du message, le plus souvent à des fins anti-spam. Le délai d’expiration limite est spécifié à 10 minutes. ^[23]

La QUITcommande met fin à la session. Si l’e-mail a d’autres destinataires situés ailleurs, le client se QUITconnectera à un serveur SMTP approprié pour les destinataires suivants après que la ou les destinations actuelles aient été mises en file d’attente. Les informations que le client envoie dans les commandes HELOet MAIL FROMsont ajoutées (non visibles dans l’exemple de code) en tant que champs d’en-tête supplémentaires au message par le serveur de réception. Il ajoute un champ Receivedet un en- Return-Pathtête, respectivement.

Certains clients sont implémentés pour fermer la connexion après l’acceptation du message ( 250 Ok: queued as 12345), de sorte que les deux dernières lignes peuvent en fait être omises. Cela provoque une erreur sur le serveur lors de la tentative d’envoi de la 221 Byeréponse.

Extensions SMTP

Mécanisme de découverte d’extensions

Les clients apprennent les options prises en charge par un serveur en utilisant le EHLOmessage d’accueil, comme illustré ci-dessous, au lieu de l’original HELO. Les clients se replient sur HELOuniquement si le serveur ne prend pas en charge le message d’ EHLOaccueil. ^[24]

Les clients modernes peuvent utiliser le mot-clé d’extension ESMTP SIZEpour demander au serveur la taille de message maximale qui sera acceptée. Les clients et serveurs plus anciens peuvent essayer de transférer des messages de taille excessive qui seront rejetés après avoir consommé des ressources réseau, y compris le temps de connexion aux liens réseau qui est payé à la minute. ^[25]

Les utilisateurs peuvent déterminer manuellement à l’avance la taille maximale acceptée par les serveurs ESMTP. Le client remplace la HELOcommande par la EHLOcommande.

S : 220 smtp2.example.com Suffixe ESMTP C : EHLO bob.exemple.org S : 250-smtp2.example.com Bonjour bob.example.org [192.0.2.201] S : 250-SIZE 14680064 S : 250-PIPELINING S : 250 HELP

Ainsi , smtp2.example.com déclare qu’il peut accepter une taille de message maximale fixe ne dépassant pas 14 680 064 octets (octets de 8 bits).

Dans le cas le plus simple, un serveur ESMTP déclare un maximum SIZEimmédiatement après avoir reçu un EHLO. Selon RFC 1870 , cependant, le paramètre numérique de l’ extension dans la réponse est facultatif. Les clients peuvent à la place, lors de l’émission d’une commande, inclure une estimation numérique de la taille du message qu’ils transfèrent, afin que le serveur puisse refuser la réception de messages trop volumineux. SIZEEHLOMAIL FROM

Transfert de données binaires

Le SMTP d’origine ne prend en charge qu’un seul corps de texte ASCII. Par conséquent, toutes les données binaires doivent être codées sous forme de texte dans ce corps du message avant le transfert, puis décodées par le destinataire. Les encodages binaires en texte , tels que uuencode et BinHex , étaient généralement utilisés.

La commande 8BITMIME a été développée pour résoudre ce problème. Il a été normalisé en 1994 sous le nom de RFC 1652 ^[26] Il facilite l’ échange transparent de messages électroniques contenant des octets en dehors du jeu de caractères ASCII à sept bits en les codant en tant que parties de contenu MIME , généralement codées avec Base64 .

Extensions du mécanisme de livraison du courrierRelais de messagerie à la demande

Le relais de messagerie à la demande ( ODMR ) est une extension SMTP normalisée dans la RFC 2645 qui permet à un serveur SMTP connecté par intermittence de recevoir des e-mails mis en file d’attente lorsqu’il est connecté.

Extension d’internationalisation

Le SMTP d’origine prend uniquement en charge les adresses e-mail composées de caractères ASCII , ce qui n’est pas pratique pour les utilisateurs dont le script natif n’est pas basé sur le latin ou qui utilisent des signes diacritiques qui ne font pas partie du jeu de caractères ASCII. Cette limitation a été atténuée par des extensions permettant l’UTF-8 dans les noms d’adresse. La RFC 5336 a introduit la commande expérimentale ^[25] et a ensuite été remplacée par la RFC 6531 qui a introduit la commande. Ces extensions prennent en charge les caractères multi-octets et non ASCII dans les adresses e-mail, telles que celles avec des signes diacritiques et d’autres caractères linguistiques tels que le grec et le chinois . ^[27] UTF8SMTP SMTPUTF8

La prise en charge actuelle est limitée, mais il existe un vif intérêt pour une large adoption de la RFC 6531 et des RFC associées dans des pays comme la Chine qui ont une large base d’utilisateurs où le latin (ASCII) est une écriture étrangère.

Rallonges

Comme SMTP, ESMTP est un protocole utilisé pour transporter le courrier Internet. Il est utilisé à la fois comme protocole de transport inter-serveurs et (avec un comportement restreint appliqué) comme protocole de soumission de courrier.

La principale fonction d’identification pour les clients ESMTP est d’ouvrir une transmission avec la commande EHLO(Extended HELLO), plutôt que HELO(Hello, la norme RFC 821 d’origine ). Un serveur répondra avec succès (code 250), échec (code 550) ou erreur (code 500, 501, 502, 504 ou 421), selon sa configuration. Un serveur ESMTP renvoie le code 250 OK dans une réponse multiligne avec son domaine et une liste de mots-clés pour indiquer les extensions prises en charge. Un serveur conforme RFC 821 renvoie le code d’erreur 500, permettant aux clients ESMTP d’essayer soit ou . HELOQUIT

Chaque extension de service est définie dans un format approuvé dans les RFC ultérieures et enregistrée auprès de l’ IANA ( Internet Assigned Numbers Authority ). Les premières définitions étaient les services optionnels RFC 821 : SEND, SOML(Send or Mail), SAML(Send and Mail), EXPN, HELPet TURN. Le format des verbes SMTP supplémentaires a été défini et pour les nouveaux paramètres dans MAILet RCPT.

Certains mots-clés relativement courants (qui ne correspondent pas tous à des commandes) utilisés aujourd’hui sont :

• 8BITMIME – Transmission de données 8 bits, RFC 6152
• ATRN – Authentifié TURNpour le relais de messagerie à la demande , RFC 2645
• AUTH – SMTP authentifié, RFC 4954
• CHUNKING – Regroupement, RFC 3030
• DSN – Notification d’état de livraison, RFC 3461 (Voir Chemin de retour d’enveloppe variable )
• ETRN – Version étendue de la commande de démarrage de file d’attente de messages à distance TURN, RFC 1985
• HELP – Fournir des informations utiles, RFC 821
• PIPELINING – Canalisation de commandes, RFC 2920
• SIZE – Déclaration de taille de message, RFC 1870
• STARTTLS – Sécurité de la couche transport , RFC 3207 (2002)
• SMTPUTF8 – Autoriser le codage UTF-8 dans les noms de boîtes aux lettres et les champs d’en-tête, RFC 6531
• UTF8SMTP – Autoriser le codage UTF-8 dans les noms de boîtes aux lettres et les champs d’en-tête, RFC 5336 (obsolète ^[28] )

Le format ESMTP a été reformulé dans la RFC 2821 (remplaçant la RFC 821) et mis à jour avec la dernière définition de la RFC 5321 en 2008. La prise en charge de la commande dans les serveurs est devenue obligatoire et a désigné une solution de secours requise. EHLOHELO

Les extensions de service non standard, non enregistrées, peuvent être utilisées par accord bilatéral. Ces services sont indiqués par un EHLOmot-clé de message commençant par “X”, et avec tous les paramètres ou verbes supplémentaires marqués de manière similaire.

Les commandes SMTP ne sont pas sensibles à la casse. Ils sont présentés ici sous forme de lettres majuscules à des fins d’accentuation uniquement. Un serveur SMTP qui nécessite une méthode de capitalisation spécifique est une violation de la norme. ^{[ citation nécessaire ]}

8BITMIME

Au moins les serveurs suivants annoncent l’extension 8BITMIME :

• Apache James (depuis 2.3.0a1) ^[29]
• Citadelle (depuis 7h30)
• Serveur de messagerie Courrier
• Gmail ^[30]
• Distorsion de glace
• Service SMTP IIS
• Kerio Connect
• Lotus Dominos
• Microsoft Exchange Server (à partir d’Exchange Server 2000)
• Novell GroupWise
• OpenSMTPD
• Serveur de messagerie Oracle Communications
• Suffixe
• Sendmail (depuis 6.57)

Les serveurs suivants peuvent être configurés pour annoncer 8BITMIME, mais n’effectuent pas la conversion des données 8 bits en 7 bits lors de la connexion à des relais non 8BITMIME :

• Exim et qmail ne traduisent pas les messages huit bits en sept bits lorsqu’ils tentent de relayer des données 8 bits vers des pairs non 8BITMIME, comme l’exige la RFC. ^[31] Cela ne pose pas de problèmes en pratique, puisque pratiquement tous les relais de messagerie modernes sont 8 bits propres . ^[32]
• Microsoft Exchange Server 2003 annonce 8BITMIME par défaut, mais le relais vers un homologue non-8BITMIME entraîne un rebond. Ceci est autorisé par la RFC 6152 section 3 .

SMTP-AUTH

L’extension SMTP-AUTH fournit un mécanisme de contrôle d’accès. Il consiste en une étape d’ authentification par laquelle le client se connecte effectivement au serveur de messagerie pendant le processus d’envoi du courrier. Les serveurs qui prennent en charge SMTP-AUTH peuvent généralement être configurés pour exiger que les clients utilisent cette extension, garantissant que la véritable identité de l’expéditeur est connue. L’extension SMTP-AUTH est définie dans RFC 4954 .

SMTP-AUTH peut être utilisé pour permettre aux utilisateurs légitimes de relayer le courrier tout en refusant le service de relais aux utilisateurs non autorisés, tels que les spammeurs . Cela ne garantit pas nécessairement l’authenticité de l’ expéditeur de l’enveloppe SMTP ou de l’ en-tête RFC 2822 “From:”. Par exemple, l’ usurpation d’identité , dans laquelle un expéditeur se fait passer pour quelqu’un d’autre, est toujours possible avec SMTP-AUTH à moins que le serveur ne soit configuré pour limiter les adresses d’envoi des messages aux adresses pour lesquelles cet utilisateur AUTHé est autorisé.

L’extension SMTP-AUTH permet également à un serveur de messagerie d’indiquer à un autre que l’expéditeur a été authentifié lors du relais du courrier. En général, cela nécessite que le serveur destinataire fasse confiance au serveur expéditeur, ce qui signifie que cet aspect de SMTP-AUTH est rarement utilisé sur Internet. ^{[ citation nécessaire ]}

SMTPUTF8

Les serveurs de support incluent :

• Postfix (version 3.0 et ultérieure) ^[33]
• Momentum (versions 4.1 ^[34] et 3.6.5, et ultérieures)
• Sendmail (en développement)
• Exim (expérimental à partir de la version 4.86)
• CommuniGate Pro à partir de la version 6.2.2 ^[35]
• Courier-MTA à partir de la version 1.0 ^[36]
• Halon à partir de la version 4.0 ^[37]
• Microsoft Exchange Server à partir de la révision du protocole 14.0 ^[38]
• Haraka et autres serveurs. ^[39]
• Oracle Communications Messaging Server à partir de la version 8.0.2. ^[40]

Extensions de sécurité

La livraison du courrier peut se produire à la fois sur des connexions en texte brut et cryptées, mais les parties communicantes peuvent ne pas savoir à l’avance la capacité de l’autre partie à utiliser un canal sécurisé.

STARTTLS ou “TLS opportuniste”

Les extensions STARTTLS permettent aux serveurs SMTP prenant en charge d’informer les clients qui se connectent qu’ils prennent en charge la communication cryptée TLS et offrent la possibilité aux clients de mettre à niveau leur connexion en envoyant la commande STARTTLS. Les serveurs prenant en charge l’extension ne tirent intrinsèquement aucun avantage en matière de sécurité de sa mise en œuvre, car la mise à niveau vers une session chiffrée TLS dépend de la décision du client qui se connecte d’exercer cette option, d’où le terme TLS opportuniste .

STARTTLS n’est efficace que contre les attaques d’observation passives, car la négociation STARTTLS se déroule en texte brut et un attaquant actif peut supprimer trivialement les commandes STARTTLS. Ce type d’ attaque de l’homme du milieu est parfois appelé STRIPTLS , où les informations de négociation de chiffrement envoyées d’une extrémité n’atteignent jamais l’autre. Dans ce scénario, les deux parties considèrent les réponses non valides ou inattendues comme une indication que l’autre ne prend pas correctement en charge STARTTLS, par défaut le transfert de courrier en texte brut traditionnel. ^[41] Notez que STARTTLS est également défini pour IMAP et POP3dans d’autres RFC, mais ces protocoles ont des objectifs différents : SMTP est utilisé pour la communication entre les agents de transfert de messages, tandis que IMAP et POP3 sont destinés aux clients finaux et aux agents de transfert de messages.

En 2014, l’ Electronic Frontier Foundation a lancé le projet “STARTTLS Everywhere” qui, à l’instar de la liste ” HTTPS Everywhere “, permettait aux parties utilisatrices de découvrir d’autres prenant en charge une communication sécurisée sans communication préalable. Le projet a cessé d’accepter les soumissions le 29 avril 2021 et l’EFF a recommandé de passer à DANE et MTA-STS pour découvrir des informations sur la prise en charge TLS des pairs. ^[42]

La RFC 8314 a officiellement déclaré le texte brut obsolète et recommande de toujours utiliser TLS, en ajoutant des ports avec TLS implicite.

Sécurité de transport stricte MTA SMTP

Une RFC 8461 plus récente de 2018 appelée “SMTP MTA Strict Transport Security (MTA-STS)” vise à résoudre le problème de l’adversaire actif en définissant un protocole permettant aux serveurs de messagerie de déclarer leur capacité à utiliser des canaux sécurisés dans des fichiers spécifiques sur le serveur et des DNS spécifiques. Enregistrements TXT. La partie utilisatrice vérifierait régulièrement l’existence d’un tel enregistrement et le mettrait en cache pendant la durée spécifiée dans l’enregistrement et ne communiquerait jamais sur des canaux non sécurisés jusqu’à l’expiration de l’enregistrement. ^[41] Notez que les enregistrements MTA-STS s’appliquent uniquement au trafic SMTP entre les serveurs de messagerie, tandis que les communications entre le client d’un utilisateur et le serveur de messagerie sont protégées par Transport Layer Security avec SMTP/MSA, IMAP, POP3 ou HTTPS . en combinaison avec une politique organisationnelle ou technique. MTA-STS est essentiellement un moyen d’étendre une telle politique à des tiers.

En avril 2019, Google Mail a annoncé la prise en charge de MTA-STS. ^[43]

Rapports SMTP TLS

Un certain nombre de protocoles permettent une livraison sécurisée des messages, mais ils peuvent échouer en raison de mauvaises configurations ou d’interférences actives délibérées, entraînant des messages non livrés ou une livraison sur des canaux non chiffrés ou non authentifiés. RFC 8460 “SMTP TLS Reporting” décrit un mécanisme et un format de rapport pour le partage de statistiques et d’informations spécifiques sur les échecs potentiels avec les domaines destinataires. Les domaines destinataires peuvent ensuite utiliser ces informations pour détecter les attaques potentielles et diagnostiquer les erreurs de configuration involontaires.

En avril 2019, Google Mail a annoncé la prise en charge des rapports SMTP TLS. ^[43]

Usurpation et spam

La conception originale de SMTP n’avait aucune possibilité d’authentifier les expéditeurs ou de vérifier que les serveurs étaient autorisés à envoyer en leur nom, de sorte que l’usurpation d’e-mails est possible et couramment utilisée dans les spams et le phishing .

Des propositions occasionnelles sont faites pour modifier en profondeur SMTP ou le remplacer complètement. Un exemple en est Internet Mail 2000 , mais ni lui, ni aucun autre n’a fait beaucoup de progrès face à l’ effet réseau de l’énorme base installée de SMTP classique.

Au lieu de cela, les serveurs de messagerie utilisent désormais une gamme de techniques, telles que l’application plus stricte de normes telles que RFC 5322 , ^{[44] [45]} DomainKeys Identified Mail , Sender Policy Framework et DMARC , DNSBL et la mise en liste grise pour rejeter ou mettre en quarantaine les e-mails suspects. ^[46]

Implémentations Demandes de commentaires connexes

• RFC 1123 – Exigences pour les hôtes Internet – Application et prise en charge (STD 3)
• RFC 1870 – Extension de service SMTP pour la déclaration de taille de message (obsolète : RFC 1653 )
• RFC 2505 – Recommandations anti-spam pour les MTA SMTP (BCP 30)
• RFC 2821 – Protocole de transfert de courrier simple
• RFC 2920 – Extension de service SMTP pour le pipeline de commandes (STD 60)
• RFC 3030 – Extensions de service SMTP pour la transmission de messages MIME volumineux et binaires
• RFC 3207 – Extension de service SMTP pour SMTP sécurisé sur Transport Layer Security (obsolète RFC 2487 )
• RFC 3461 – Extension de service SMTP pour les notifications d’état de livraison (obsolète RFC 1891 )
• RFC 3463 – Codes d’état améliorés pour SMTP (obsolète RFC 1893 , mis à jour par RFC 5248 )
• RFC 3464 – Un format de message extensible pour les notifications d’état de livraison (obsolète RFC 1894 )
• RFC 3798 – Notification de disposition des messages (mises à jour RFC 3461 )
• RFC 3834 – Recommandations pour les réponses automatiques au courrier électronique
• RFC 3974 – Expérience opérationnelle SMTP dans des environnements mixtes IPv4/v6
• RFC 4952 – Présentation et cadre pour les e-mails internationalisés (mise à jour par RFC 5336 )
• RFC 4954 – Extension de service SMTP pour l’authentification (obsolète RFC 2554 , met à jour RFC 3463 , mis à jour par RFC 5248 )
• RFC 5068 – Opérations de soumission d’e-mails : exigences d’accès et de responsabilité (BCP 134)
• RFC 5248 – Un registre pour les codes d’état du système de messagerie amélioré SMTP (BCP 138) (mises à jour RFC 3463 )
• RFC 5321 – Le protocole de transfert de courrier simple (obsolète RFC 821 alias STD 10, RFC 974 , RFC 1869 , RFC 2821 , met à jour RFC 1123 )
• RFC 5322 – Format de message Internet (obsolète RFC 822 alias STD 11 et RFC 2822 )
• RFC 5504 – Mécanisme de rétrogradation pour l’internationalisation des adresses e-mail
• RFC 6409 – Message Submission for Mail (STD 72) (obsolète RFC 4409 , RFC 2476 )
• RFC 6522 – Le type de contenu multipart/rapport pour le rapport des messages administratifs du système de messagerie (obsolète RFC 3462 , puis RFC 1892 )
• RFC 6531 – Extension SMTP pour les adresses e-mail internationalisées (mises à jour RFC 2821 , RFC 2822 , RFC 4952 et RFC 5336 )
• RFC 8314 – Texte en clair considéré comme obsolète : utilisation de Transport Layer Security (TLS) pour la soumission et l’accès aux e-mails

Voir également

• Adresse de rebond
• CRAM-MD5 (un mécanisme SASL pour ESMTPA) RFC 2195
• E-mail
  • Cryptage des e-mails
• DKIM
• Ident
• Liste des logiciels de serveur de messagerie
• Liste des codes de retour du serveur SMTP
• POP avant SMTP / SMTP après POP
• Extension de contenu binaire du protocole d’accès aux messages Internet RFC 3516
• Cadre de politique de l’expéditeur (SPF)
• Authentification simple et couche de sécurité (SASL) RFC 4422
• Authentification SMTP
• Chemin de retour d’enveloppe variable
• Comparaison des clients de messagerie pour plus d’informations sur la prise en charge SMTP

Remarques

1. ^ L’histoire du courrier électronique , Tom Van Vleck : “ Il n’est pas clair que ce protocole ait jamais été mis en œuvre “
2. ^ Le premier e-mail réseau , Ray Tomlinson , BBN
3. ^ Image de ” The First Email Computer ” par Dan Murphy, un PDP-10
4. ^ Les articles TENEX et TOPS-20 de Dan Murphy archivés le 18 novembre 2007 à la Wayback Machine
5. ^ RFC 524 – Un protocole de messagerie proposé
6. ^ Crocker, David H. (décembre 1977). “Cadre et fonctions du système de messagerie personnelle” MS “” (PDF) . La société Rand .
7. ^ RFC 469 – Résumé de la réunion de messagerie réseau
8. ^ RFC 733, 21 novembre 1977, Norme pour le format du message texte du réseau ARPA
9. ^ “Tldp.org” .
10. ^ “draft-barber-uucp-project-conclusion-05 – La conclusion du projet de cartographie UUCP” .
11. ^ L’article sur la réécriture de l’expéditeur contient des informations techniques sur l’historique SMTP et le routage source avant la RFC 1123 .
12. ^ Eric Allman (1983), Sendmail – An Internetwork Mail Router (PDF) , ensemble de documentation BSD UNIX, Berkeley: University of California , récupéré le 29 juin 2012
13. ^ Craig Partridge (2008), Le développement technique du courrier électronique Internet (PDF) , IEEE Annals of the History of Computing, vol. 30, IEEE Computer Society, pp. 3–29, doi : 10.1109/MAHC.2008.32 , S2CID 206442868 , archivé de l’original (PDF) le 12 mai 2011
14. ^ Paul Hoffman (1er février 1998). “Autoriser le relais dans SMTP : une enquête” . Consortium de messagerie Internet . Consulté le 30 mai 2010 .
15. ^ Paul Hoffman (août 2002). “Autoriser le relais dans SMTP : une série d’enquêtes” . Consortium de messagerie Internet . Archivé de l’original le 18 janvier 2007 . Consulté le 30 mai 2010 .
16. ^ “Sous Unix, qu’est-ce qu’un relais de messagerie ouvert ? – Base de connaissances” . 17 juin 2007. Archivé de l’original le 17 juin 2007 . Consulté le 15 mars 2021 .
17. ^ “Les verbes MAIL, RCPT et DATA” , [DJ Bernstein]
18. ^ RFC 5321 Section-7.2
19. ^ Systèmes, Message. “Message Systems présente la dernière version de Momentum avec de nouvelles fonctionnalités basées sur l’API” . www.prnewswire.com . Consulté le 19 juillet 2020 .
20. ^ Cara Garretson (2005). “Les FAI interviennent pour arrêter le spam” . PC Monde . Consulté le 18 janvier 2016 . Le mois dernier, l’Alliance technique anti-spam, formée l’année dernière par Yahoo, America Online, EarthLink et Microsoft, a publié une liste de recommandations anti-spam incluant le filtrage du port 25.
21. ^ RFC 5321 , Protocole de transfert de courrier simple , J. Klensin, The Internet Society (octobre 2008)
22. ^ RFC 1047
23. ^ “rfc5321#section-4.5.3.2.6” .
24. ^ John Klensin; Ned Freed ; Marshall T. Rose ; Einar A. Stefferud; Dave Crocker (novembre 1995). Extensions de service SMTP . IETF . doi : 10.17487/RFC1869 . RFC 1869 .
25. ^ ^{un b} “Paramètres de COURRIER” . IANA. 14 février 2020.
26. ↑ Qui a été rendu obsolète en 2011 par la RFC 6152 correspondant au nouveau STD 71
27. ^ Jiankang Yao (19 décembre 2014). “Adresse e-mail chinoise” . EAI (liste de diffusion). IETF . Consulté le 24 mai 2016 .
28. ^ “Paramètres d’extension de service SMTP” . IANA . Consulté le 5 novembre 2013 .
29. ^ Serveur James – ChangeLog . James.apache.org. Consulté le 17/07/2013.
30. ^ Service 8BITMIME annoncé en réponse à EHLO sur gmail-smtp-in.l.google.com port 25, vérifié le 23 novembre 2011
31. ^ Bogues Qmail et liste de souhaits . Home.pages.de. Consulté le 17/07/2013.
32. ^ L’extension 8BITMIME . Cr.yp.to. Consulté le 17/07/2013.
33. ^ ” La prise en charge de Postfix SMTPUTF8 est activée par défaut ” , 8 février 2015, postfix.org
34. ^ “Message Systems présente la dernière version de Momentum avec de nouvelles capacités pilotées par l’API” (communiqué de presse).
35. ^ “Historique de révision de la version 6.2” . CommuniGate.com .
36. ^ Sam Varshavchik (18 septembre 2018). “Nouvelles versions des packages Courier” . annonce par courrier (liste de diffusion).
37. ^ “Journal des modifications Halon MTA” . GitHub . 9 novembre 2021. v4.0 : nouvelle prise en charge de SMTPUTF8 Mis à jour pour les nouvelles versions
38. ^ “MS-OXSMTP : Extensions du protocole de transfert de courrier simple (SMTP)” . 24 juillet 2018.
39. ^ ” Préparation EAI dans les TLD ” (PDF) . 12 février 2019.
40. ^ “Notes de version du serveur de messagerie de communications” . oracle.com . Octobre 2017.
41. ^ ^{un b} “Présentant MTA Strict Transport Security (MTA-STS) | Hardenize Blog” . www.hardenize.com . Consulté le 25 avril 2019 .
42. ^ “STARTTLS Partout” . EFF . Consulté le 4 décembre 2021 .
43. ^ ^{un b} Cimpanu, Catalin. “Gmail devient le premier fournisseur de messagerie majeur à prendre en charge les rapports MTA-STS et TLS” . ZDNet . Consulté le 25 avril 2019 .
44. ^ “Message non conforme à la RFC 5322” .
45. ^ “Le message n’a pas pu être livré. Veuillez vous assurer que le message est conforme à la RFC 5322” .
46. ^ “Pourquoi les e-mails envoyés au compte Microsoft sont-ils rejetés pour des raisons de politique ?” .

Références

• Hughes, L (1998). Courriel Internet : protocoles, normes et mise en œuvre . Editeurs Maison Artech. ISBN 978-0-89006-939-4.
• Hunt, C (2003). sendmail Livre de recettes . O’Reilly Media. ISBN 978-0-596-00471-2.
• Johnson, K (2000). Protocoles de messagerie Internet : Guide du développeur . Addison-Wesley Professionnel. ISBN 978-0-201-43288-6.
• Loshin, P (1999). Normes de messagerie essentielles : RFC et protocoles rendus pratiques . John Wiley et fils. ISBN 978-0-471-34597-8.
• Rhoton, J (1999). Guide du programmeur de messagerie Internet : SMTP, POP, IMAP et LDAP . Elsevier. ISBN 978-1-55558-212-8.
• Bois, D (1999). Programmation de la messagerie Internet . O’Reilly. ISBN 978-1-56592-479-6.

Liens externes

• Extensions de service SMTP RFC 1869
• Protocole de transfert de courrier simple RFC 5321
• Extension de service SMTP RFC 4954 pour l’authentification (obsolète RFC 2554 )
• Enregistrement des types de transmission RFC 3848 SMTP et LMTP (avec ESMTPA)
• RFC 6409 Message Submission for Mail (obsolète RFC 4409 , qui obsolète RFC 2476 )