aeris22’s avataraeris22’s Twitter Archive—№ 64,336

    1. Ç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
  1. …in reply to @aeris22
    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
    1. …in reply to @aeris22
      la même machine qui revient présenter le message à la 2nde tentative. Sinon vous repartez pour 5 à 15min d’attente.
      1. …in reply to @aeris22
        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.
        1. …in reply to @aeris22
          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*
          1. …in reply to @aeris22
            1h10 avant de commencer à vous plaindre que vous ne l’avez pas reçu !!!!
            1. …in reply to @aeris22
              (Ah oui, ça veut dire aussi que vous n’aurez possiblement pas de réponse de votre correspondant avant 2h30 aussi, du coup 😂)
        2. …in reply to @aeris22
          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**.
          1. …in reply to @aeris22
            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.