Relances, expirations et données renvoyées

Le serveur de livraison effectue une tentative de transmission d'un paquet à un autre hôte. Si le paquet ne peut pas être transmis (si l'hôte destinataire n'est pas disponible par exemple), le serveur de livraison génère un message d'erreur et une entrée de journal et quitte.
Vous pouvez définir une syntaxe de relance pour contrôler sa fréquence :
Les tentatives de transmission d'un paquet non livré peuvent se poursuivre indéfiniment, via des appels répétés de la commande shipping_server. Cependant, vous souhaitez généralement résoudre les incidents liés aux échecs de transmission au lieu de laisser les tentatives se poursuivre. Chaque instruction de livraison peut donc inclure une date d'expiration, indiquée de l'une des façons suivantes :

Par défaut, les instructions de livraison expirent 14 jours après leur création.

Lorsque le serveur de livraison rencontre une instruction de livraison arrivée à expiration, il ne tente pas de transmettre le paquet correspondant à sa destination. Il procède comme suit :

Le retour peut impliquer plusieurs hôtes. Lors de ce retour, un paquet est placé dans la baie de retour de chaque hôte intermédiaire. Chaque transfert d'un hôte à un autre est géré par shipping_server –poll, qui traite la baie de retour d'un hôte en plus de ses baies de stockage. Le délai d'expiration du retour d'un paquet est de 14 jours. Un paquet qui ne peut pas être renvoyé dans ce délai est supprimé.

Concepts associés
Configuration d'une route de livraison indirecte
Référence associée
shipping.conf
MultiSite Control Panel
shipping_server

Retour d'informations