Salut,
Il n'avait pas encore été question de Push Mail, c'est vrai que c'est aussi quelque chose qui peut contribuer à faire croire que les mails peuvent être reçus instantanément.
Je crois que quelques rappels s'imposent pour tordre le cou à cette idée totalement fausse. Le circuit suivi par les mails est le suivant (sibsib - ou autre - complète/corrige si nécessaire : je suis très loin d'être un spécialiste de la messagerie !) :
- Code : Tout sélectionner
MUA -- (SMTP) -- MTA --- (SMTP) -- Autres MTA -- (SMTP) -- MDA
[EDIT] Pour la signification des abréviations,
voir ci-dessous le post d'unnilennium.[/EDIT]
Une fois pris en charge par le MDA du destinataire, le mail peut suivre 3 chemins différents avant de s'afficher sur son écran (je considère ici webmail comme un vulgaire MUA) :
- Code : Tout sélectionner
M -- (Push) -- MUA spécial
D -- (POP ou IMAP + fetchmail) -- MDA -- (un de ces trois mêmes circuits)
A -- (POP ou IMAP) -- MUA
Partant du MUA de l'expéditeur, le mail est pris en charge par le MTA dont il dépend. Ce MTA le fait suivre, en passant par autant d'autres MTA que nécessaire, jusqu'au MDA du destinataire.
Il est assez exceptionnel que le nombre de MTA dans le circuit soit de un ou deux, leur nombre est parfois impressionnant, les FAI et autres gros opérateurs en ayant généralement plusieurs, chacun spécialisé, qui se relaient les mails entre eux.
Si un MTA est conçu pour ne jamais perdre un mail, il ne peut en aucun cas assurer un délai de livraison. Il va rechercher quel MTA ou MDA est susceptible de poursuivre l'acheminement, prendre contact et essayer de lui transmetter le mail. Mais cet agent peut être indisponible ou surchargé : le MTA devra alors stocker temporairement le mail et tenter périodiquement d'établir le contact. Il le fera jusqu'à réponse ou timeout. En cas de timeout, il renverra le mail à l'expéditeur avec une notification de non-distribution donnant toutes les précisions utiles sur la raison du retour.
Le délai pour que le mail soit pris en charge par le MDA destinataire est donc très variable, et peut être très long. Et on voit bien que, jusque là, push ou fetchmail ne sont pas encore intervenus !
Lorsque le MDA prend en charge le mail, il peut soit le faire à nouveau suivre sur un smartphone ou autre dispositif récepteur faisant office de MUA, soit le déposer dans la BAL du destinataire.
L'opération peut, aux délais de traitement près, être considérée comme instantannée : en effet, le MDA donne toujours priorité aux mails en cours de traitement, et en cas de surcharge il s'occupera d'abord d'envoyer ce mail vers le dispositif récepteur ou de le déposer dans la BAL.
Le troisième circuit correspond à la délivrance normale d'un mail : déposé dans la BAL, il attend qu'un MUA vienne le chercher.
Pour le second circuit, le mail est déposé dans la BAL du destinataire comme pour une délivrance normale. Fetchmail vient régulièrement chercher les mails qui y sont déposés, puis les transfère à un MDA destinataire qui pourra à son tour soit le déposer dans une BAL, soit le "pousser" vers un smartphone ou similaire.
On voit bien que le traitement de push et celui par fetchmail sont totalement différents, et que celui par fetchmail est plus long. De plus, le traitement par fetchmail ne dispose pas de la priorité de traitement comme push, mais au contraire la subit.
Voilà qui, je l'espère, aidera à comprendre et à admettre une bonne fois pour toutes qu'un email est tout le contraire d'un mode de communication instantané ou rapide. Il peut l'être, mais sans garantie aucune. Et aussi que le traitement par fetchmail nécessite du temps et le respect des priorités des MDA et donc que tenter d'augmenter la fréquence de ses relèves n'est que très peu utile, voire néfaste.
Et aussi que ça aidera Paradox à prendre conscience qu'on ne lui raconte pas de bêtises en disant que ses besoins ne peuvent pas être satisfaits par ce type de solution !
, les posts de jdh et jibé résument exactement la vraie vie de SMTP.