SMTP étendu - Extended SMTP
Extended SMTP ( ESMTP ), parfois appelé Enhanced SMTP , est une définition des extensions de protocole de la norme SMTP ( Simple Mail Transfer Protocol ). ESMTP a été défini en novembre 1995 dans la publication IETF RFC 1869 qui a établi une structure générale pour toutes les extensions existantes et futures.
ESMTP définit des moyens cohérents et gérables par lesquels les clients et les serveurs ESMTP peuvent être identifiés et les serveurs peuvent indiquer les extensions prises en charge.
Extensions
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 caractéristique d'identification des 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 HELO
ou QUIT
.
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 ont été les RFC 821 services optionnels: SEND
, SOML
(Envoyer ou Mail), SAML
(Envoyer et Mail), EXPN
, HELP
et TURN
. Le format des verbes SMTP supplémentaires a été défini et pour les nouveaux paramètres dans MAIL
et RCPT
.
Certains mots-clés relativement courants (ne correspondant pas tous à des commandes) utilisés aujourd'hui sont:
-
8BITMIME
- Transmission de données 8 bits, RFC 6152 -
ATRN
- AuthentifiéTURN
pour le relais de messagerie à la demande , RFC 2645 -
AUTH
- SMTP authentifié, RFC 4954 -
CHUNKING
- Chunking, 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 la file d'attente de messages distanteTURN
, RFC 1985 -
HELP
- Fournir des informations utiles, RFC 821 -
PIPELINING
- Pipeline de commande, RFC 2920 -
SIZE
- Déclaration de taille de message, RFC 1870 -
STARTTLS
- Sécurité de la couche de 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)
Le format ESMTP a été reformulé dans la RFC 2821 (remplaçant la RFC 821 ) et mis à jour à la dernière définition de la RFC 5321 en 2008. La prise en charge de la EHLO
commande dans les serveurs est devenue obligatoire et a HELO
désigné une solution de secours obligatoire.
Les extensions de service non standard et non enregistrées peuvent être utilisées par accord bilatéral, ces services sont indiqués par un EHLO
mot-clé de message commençant par "X", et par tout paramètre ou verbe supplémentaire marqué de la même manière.
Les commandes SMTP ne sont pas sensibles à la casse. Ils sont présentés ici sous forme de majuscules pour accentuer uniquement. Un serveur SMTP qui nécessite une méthode de capitalisation spécifique est une violation de la norme.
Liste des serveurs pris en charge
- IceWarp
- Postfix - aucun correctif requis pour RFC 6531 .. RFC 6533 .
- Sendmail - correctif de code source nécessaire pour la prise en charge de SMTPUTF8
- HMailServer - serveur de messagerie gratuit pour Windows
- Exim
- MailEnable - prise en charge uniquement dans Enterprise Edition
- MagicMail - le revêtement de tuyaux n'est pas pris en charge intentionnellement
8BITMIME
Liste des serveurs pris en charge
Au moins les serveurs suivants annoncent l'extension 8BITMIME:
- Apache James (depuis 2.3.0a1)
- Citadelle (depuis 7h30)
- Serveur de messagerie Courier
- Exim
- Gmail
- IceWarp
- Service SMTP IIS
- Kerio Connect
- Lotus Domino
- Microsoft Exchange Server (à partir d'Exchange Server 2000)
- Novell GroupWise
- OpenSMTPD
- Serveur de messagerie Oracle Communications
- Postfix
- Sendmail (depuis 6.57)
- SubEtha
Les serveurs suivants peuvent être configurés pour annoncer 8BITMIME, mais n'effectuent pas de conversion de données 8 bits en 7 bits lors de la connexion à des relais non 8BITMIME:
- Exim et qmail ne traduisent pas les messages de huit bits en sept bits lors d'une tentative de relayer des données de 8 bits vers des homologues non 8BITMIME, comme l'exige la RFC. Cela ne pose pas de problème dans la pratique, car pratiquement tous les relais de messagerie modernes sont propres 8 bits .
- 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 section 3 de la RFC 6152 .
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 efficacement au serveur de messagerie pendant le processus d'envoi du courrier. Les serveurs prenant en charge SMTP-AUTH peuvent généralement être configurés pour exiger que les clients utilisent cette extension, garantissant ainsi la véritable identité de l'expéditeur. L'extension SMTP-AUTH est définie dans la 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 . Il ne garantit pas nécessairement l'authenticité de l' expéditeur d'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'expédition des messages aux adresses pour lesquelles cet utilisateur AUTHed 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 d'envoi, ce qui signifie que cet aspect de SMTP-AUTH est rarement utilisé sur Internet.
SMTPUTF8
Liste des serveurs pris en charge
- Postfix (version 3.0 et ultérieure)
- Momentum (versions 4.1 et 3.6.5 et ultérieures)
- Sendmail (en cours de développement)
- Exim (expérimental à partir de la version 4.86)
- CommuniGate Pro à partir de la version 6.2.2
- Courier-MTA à partir de la version 1.0
- Halon à partir de la version 4.0
- Microsoft Exchange Server à partir de la révision de protocole 14.0
- Haraka et autres serveurs.
- Oracle Communications Messaging Server à partir de la version 8.0.2.
Liste des serveurs locaux pris en charge
Serveurs de livraison locaux (LMTP)
- Aucun
Liste des clients de soutien
- nmh (à partir de la version 1.7)
Liste des filtres de contenu pris en charge
- Amavis (SMTP et LMTP) depuis la version 2.10.0
Voir également
- Authentification SMTP
- CRAM-MD5 (un mécanisme SASL pour ESMTPA) RFC 2195
- Authentification simple et couche de sécurité (SASL) RFC 4422
- Liste des logiciels de serveur de messagerie
- RFC 3516, Extension de contenu binaire du protocole d'accès aux messages Internet
Les références
Liens externes
- Le registre IANA des paramètres de messagerie comprend des mots clés d'extension de service
- Extensions de service SMTP RFC 1869
- Protocole de transfert de courrier simple RFC 5321
- RFC 4954 - Extension de service SMTP pour l'authentification (obsolète RFC 2554 )
- RFC 3848 - Enregistrement des types de transmission SMTP et LMTP (avec ESMTPA)
- RFC 6409 - Message Submission for Mail (obsolète la RFC 4409 , qui rend obsolète la RFC 2476 )