1. Introduction

SMTP a été défini comme un protocole de transfert de messages, c'est-à-dire un moyen d'acheminer (si nécessaire) et de livrer des messages finis (complets).

Les agents de transfert de messages (MTA) ne sont pas censés modifier le texte du message, sauf pour ajouter des champs d'en-tête 'Received', 'Return-Path' et autres, comme l'exige [SMTP-MTA].

Cependant, SMTP est maintenant aussi largement utilisé comme protocole de soumission de messages, c'est-à-dire un moyen pour les agents utilisateurs de messages (MUA) d'introduire de nouveaux messages dans le réseau de routage MTA. Le processus qui accepte les soumissions de messages des MUA est appelé agent de soumission de messages (MSA).

Afin de permettre des communications sans contraintes, SMTP n'est souvent pas authentifié lors du relais de messages.

L'authentification et l'autorisation des soumissions initiales sont devenues de plus en plus importantes, motivées par l'évolution des exigences de sécurité et les attentes croissantes selon lesquelles les serveurs de soumission assument la responsabilité du trafic de messages qu'ils génèrent.

Par exemple, en raison de la prévalence de machines infectées par des vers, des virus ou d'autres logiciels malveillants qui génèrent de grandes quantités de spam, de nombreux sites interdisent désormais le trafic sortant sur le port SMTP standard (port 25), canalisant toutes les soumissions de courrier via des serveurs de soumission.

En plus des problèmes d'authentification et d'autorisation, les messages soumis sont dans certains cas des messages finis (complets), et dans d'autres cas sont inachevés (incomplets) sur un ou plusieurs aspects. Les messages inachevés peuvent devoir être complétés pour s'assurer qu'ils sont conformes à [MESSAGE-FORMAT], et aux exigences ultérieures. Par exemple, le message peut manquer d'un champ d'en-tête 'Date' approprié, et les domaines peuvent ne pas être entièrement qualifiés. Dans certains cas, le MUA peut être incapable de générer des messages finis (par exemple, il peut ne pas connaître son fuseau horaire). Même lorsque les messages soumis sont complets, la politique locale du site peut dicter que le texte du message soit examiné ou modifié d'une manière ou d'une autre, par exemple, pour dissimuler des noms locaux ou des espaces d'adressage. De tels compléments ou modifications se sont avérés causer des dommages lorsqu'ils sont effectués par des MTA en aval -- c'est-à-dire des MTA après le MTA de soumission du premier saut -- et sont en général considérés comme étant hors du domaine de la fonctionnalité MTA normalisée.

La séparation des messages en soumissions et transferts permet aux développeurs et aux administrateurs réseau de faire plus facilement ce qui suit :

• Mettre en œuvre des politiques de sécurité et se prémunir contre le relais de courrier non autorisé ou l'injection de courrier en masse non sollicité

• Mettre en œuvre la soumission authentifiée, y compris la soumission hors site par des utilisateurs autorisés tels que les voyageurs

• Séparer les différences de code logiciel pertinentes, rendant ainsi chaque base de code plus simple et permettant différents programmes pour le relais et la soumission

• Détecter les problèmes de configuration avec les clients de messagerie d'un site

• Fournir une base pour ajouter des services de soumission améliorés à l'avenir

Ce mémoire décrit un moyen peu coûteux et déterministe pour que les messages soient identifiés comme des soumissions, et spécifie quelles actions doivent être prises par un serveur de soumission.