3. Soumission de messages
3.1. Identification de la soumission
Le port 587 est réservé à la soumission de messages électroniques comme spécifié dans ce document. Les messages reçus sur ce port sont définis comme des soumissions. Le protocole utilisé est ESMTP [SMTP-MTA, ESMTP], avec des restrictions ou autorisations supplémentaires comme spécifié ici.
Bien que la plupart des clients et serveurs de messagerie puissent être configurés pour utiliser le port 587 au lieu du 25, il existe des cas où cela n'est pas possible ou pratique. Un site PEUT choisir d'utiliser le port 25 pour la soumission de messages, en désignant certains hôtes comme MSA et d'autres comme MTA.
3.2. Rejet et rebond de messages
Les MTA et les MSA PEUVENT mettre en œuvre des règles de rejet de messages qui reposent en partie sur le fait que le message est une soumission ou un relais.
Par exemple, certains sites peuvent configurer leurs MTA pour rejeter toutes les commandes RCPT pour les messages qui ne font pas référence à des utilisateurs locaux, et configurer leur MSA pour rejeter toutes les soumissions de messages qui ne proviennent pas d'utilisateurs autorisés, l'autorisation étant basée soit sur une identité authentifiée, soit sur le point de terminaison de soumission se trouvant dans un environnement IP protégé.
NOTE : Il est préférable de rejeter un message plutôt que de risquer d'en envoyer un qui est endommagé. Cela est particulièrement vrai pour les problèmes qui peuvent être corrigés par le MUA, par exemple, un champ 'From' invalide.
Si un MSA n'est pas en mesure de déterminer un chemin de retour vers l'utilisateur soumettant, à partir d'un MAIL FROM valide, d'une adresse IP source valide ou sur la base d'une identité authentifiée, alors le MSA DEVRAIT rejeter immédiatement le message. Un message peut être immédiatement rejeté en renvoyant un code 550 à la commande MAIL.
Notez qu'un chemin de retour nul, c'est-à-dire MAIL FROM:<>, est autorisé et NE DOIT PAS en soi être une cause de rejet d'un message. (Les MUA doivent générer des messages de chemin de retour nul pour diverses raisons, y compris les notifications de disposition.)
Sauf dans le cas où le MSA est incapable de déterminer un chemin de retour valide pour le message soumis, le texte de cette spécification qui demande à un MSA d'émettre un code de rejet PEUT être respecté en acceptant le message et en générant ensuite un message de rebond. (C'est-à-dire que si le MSA doit rejeter un message pour une raison quelconque, sauf s'il est incapable de déterminer un chemin de retour, il peut éventuellement effectuer un rejet immédiat ou accepter le message puis envoyer un rebond.)
NOTE : Dans le cas normal de soumission de message, le rejet immédiat du message est préféré, car il donne un retour direct à l'utilisateur et au MUA. Pour gérer correctement les rebonds différés, le client MUA doit maintenir une file d'attente des messages qu'il a soumis et leur faire correspondre les rebonds. Notez que de nombreux MUA contemporains n'ont pas cette capacité.
3.3. Soumission autorisée
De nombreuses méthodes ont été utilisées pour garantir que seuls les utilisateurs autorisés sont en mesure de soumettre des messages. Ces méthodes incluent SMTP authentifié, les restrictions d'adresse IP, IP sécurisé et autres tunnels, et l'authentification POP préalable.
SMTP authentifié [SMTP-AUTH] a connu un déploiement généralisé. Il permet au MSA de déterminer une identité d'autorisation pour la soumission du message, qui n'est pas liée à d'autres protocoles.
Les restrictions d'adresse IP sont très largement mises en œuvre, mais ne permettent pas les voyageurs et les situations similaires, et peuvent être facilement usurpées à moins que tous les chemins de transport entre le MUA et le MSA ne soient dignes de confiance.
IP sécurisé [IPSEC], et d'autres techniques de tunnelage cryptées et authentifiées, peuvent également être utilisées et offrent des avantages supplémentaires de protection contre les écoutes clandestines et l'analyse du trafic.
Exiger une authentification POP [POP3] (à partir de la même adresse IP) dans un certain laps de temps (par exemple, 20 minutes) avant le début d'une session de soumission de message a également été utilisé, mais cela impose des restrictions aux clients ainsi qu'aux serveurs, ce qui peut causer des difficultés. Plus précisément, le client doit effectuer une authentification POP avant une session de soumission SMTP, et tous les clients ne sont pas capables et configurés pour cela. De plus, le MSA doit se coordonner avec le serveur POP, ce qui peut être difficile. Il existe également une fenêtre pendant laquelle un utilisateur non autorisé peut soumettre des messages et apparaître comme un utilisateur précédemment autorisé. Comme elle dépend des adresses IP du MUA, cette technique est substantiellement aussi sujette à l'usurpation d'adresse IP que la validation basée uniquement sur des adresses IP connues (voir ci-dessus).