Plus loin que le SMTP
Vivez la suite de l'article sur http://linux-attitude.fr/post/Plus-loin-que-le-SMTP
Niveau :
Résumé : Submission
Le protocole mail n'est pas mort, il évolue encore. La preuve, une RFC (2476) récente (de 1998) propose de changer la façon dont interagissent les serveurs mail. Cette évolution suit la logique de l'évolution de l'utilisation.
Au début un serveur mail servait à envoyer, recevoir et transmettre les mails. L'envoi de mail se faisait à travers une commande locale au serveur (sendmail) et la réception était locale au serveur. C'était pratique, toutes les machines connectées à internet étaient des serveurs. Puis le net a évolué et les gens devaient avoir un serveur mail chez eux pour envoyer des mails à d'autres serveurs. Et il a encore évolué lorsque les client se sont mis à implémenter eux-même l'envoi de mail à un serveur SMTP.
Et c'est là qu'on est sorti du cadre d'utilisation prévue. Le SMTP a été fait pour communiquer de serveur à serveur.
La RFC en question propose donc de différencier les 2 usages. L'envoi d'un mail depuis un client devrait se faire depuis le port submission (587), tandis que la communication entre deux serveurs reste sur le port 25. Les deux conservant le protocole SMTP.
La différence se fera donc au niveau des vérifications faites sur le serveur.
Un serveur servant à recevoir des mails devra vérifier :
Un serveur submission doit :
Un serveur submission devrait :
D'autre part, du fait de sa position privilégiée, un serveur submission peut :
L'avantage du serveur submission est qu'il permet aux administrateurs de séparer clairement les politiques pour l'envoi et pour la réception du mail. Ainsi cela standardise une pratique déjà courante d'avoir 2 serveurs séparés pour l'envoi et pour la réception du mail.
Niveau :
Résumé : Submission
Le protocole mail n'est pas mort, il évolue encore. La preuve, une RFC (2476) récente (de 1998) propose de changer la façon dont interagissent les serveurs mail. Cette évolution suit la logique de l'évolution de l'utilisation.
Au début un serveur mail servait à envoyer, recevoir et transmettre les mails. L'envoi de mail se faisait à travers une commande locale au serveur (sendmail) et la réception était locale au serveur. C'était pratique, toutes les machines connectées à internet étaient des serveurs. Puis le net a évolué et les gens devaient avoir un serveur mail chez eux pour envoyer des mails à d'autres serveurs. Et il a encore évolué lorsque les client se sont mis à implémenter eux-même l'envoi de mail à un serveur SMTP.
Et c'est là qu'on est sorti du cadre d'utilisation prévue. Le SMTP a été fait pour communiquer de serveur à serveur.
La RFC en question propose donc de différencier les 2 usages. L'envoi d'un mail depuis un client devrait se faire depuis le port submission (587), tandis que la communication entre deux serveurs reste sur le port 25. Les deux conservant le protocole SMTP.
La différence se fera donc au niveau des vérifications faites sur le serveur.
Un serveur servant à recevoir des mails devra vérifier :
- que le destinataire est valide et accepté localement
Un serveur submission doit :
- fournir de nouveaux codes d'erreur pour que le client mail puisse mieux interpréter les problèmes
- envoyer des mails uniquement avec des domaines valides dans l'enveloppe
- vérifier si possible que les adresses fournies sont valides
Un serveur submission devrait :
- répondre par un code d'erreur en cas de rejet et non par un mail au return path
- vérifier que l'émetteur est valide et reconnu comme utilisateur par le serveur (voire l'authentifier) et donc que le chemin de retour est valable
- rejeter les mails avec des adresses connues comme invalides
- loguer les erreurs
D'autre part, du fait de sa position privilégiée, un serveur submission peut :
- vérifier les droit d'envoi des utilisateurs
- demander une authentification
- vérifier la validité du contenu du mail
- modifier les en-têtes du mail : champ date, sender, message-id ...
L'avantage du serveur submission est qu'il permet aux administrateurs de séparer clairement les politiques pour l'envoi et pour la réception du mail. Ainsi cela standardise une pratique déjà courante d'avoir 2 serveurs séparés pour l'envoi et pour la réception du mail.