-
Ça me fera toujours marrer les gens qui mettent « urgent » et « email » dans la même phrase. Avez-vous réellement lu le RFC 5321 ? tools.ietf.org/html/rfc5321
-
En TLDR, la séquence de timeout principale est déjà à 35min *SI TOUT SE PASSE BIEN* (ie sans erreur rencontrée). Ajoutez le greylisting moderne, vous ne pourrez délivrer votre message qu’au bout de 5 à 15min généralement. Et ça c’est en supposant que vous avez du bol et que c’est
-
la même machine qui revient présenter le message à la 2nde tentative. Sinon vous repartez pour 5 à 15min d’attente.
-
Ah oui, et du coup avec du greylisting, vous pouvez donc avoir 5min + 15min + 35min d’attente avant d’avoir le mail de délivré. Et tout ce sera *BIEN* passé dans ce cas-là un. Ce n’est *PAS* un cas d’erreur.
-
My bad, j’ai oublié le délai de retry qui devrait être d’au moins 30 minutes selon le RFC. C’est donc 5 min (timeout sur le 220) + 30 min (délai d’attente entre 2 tentatives) + 35 min (timeout jusqu’au DATA termination). Donc si vous ne recevez pas un mail, patientez *AU MOINS*
-
1h10 avant de commencer à vous plaindre que vous ne l’avez pas reçu !!!!
-
(Ah oui, ça veut dire aussi que vous n’aurez possiblement pas de réponse de votre correspondant avant 2h30 aussi, du coup 😂)
-
S’il y a réellement un cas d’erreur ie votre message ne passe pas la 1ère fois pour une raison ou une autre ? Le RFC indique que l’émetteur devra réessayer. Durant *AU MOINS* 4 à 5 **jours**.
-
Bref, si vous voulez avoir la certitude que votre destinataire reçoit rapidement une information, oubliez le mail. On attend d’un protocole lent et asynchrone d’être instantané et synchrone. XMPP est plus adapté pour ça.
aeris22’s Twitter Archive—№ 64,338