¿Qué explica que el mismo correo no se reenvíe a los usuarios al menos en los mismos 15 minutos?
Supongo que tiene una gran cantidad de personas a las que reenvía correo en una red o servidor relativamente ocupado.
Los servidores de correo a menudo tienen retrasos cuando hay una incapacidad para realizar una transacción. Cuando no se puede realizar una transacción, muchos servidores de correo esperarán un período de tiempo (que puede o no ser configurable) antes de volver a intentar enviar cualquier elemento de correo. Esto podría suceder varias veces seguidas.
Del mismo modo, los servidores de correo a menudo realizan envíos masivos en lotes. Una cosa para recordar acerca del envío por lotes es que puede haber una demora automática entre lotes para evitar que los correos sean tratados como spam o que de otra manera abrumen al receptor. Nuevamente, este retraso puede o no ser configurable.
El resultado es examinar el servidor y su red para detectar cuellos de botella que podrían estar obstaculizando el envío efectivo de su correo. Pero tenga en cuenta que puede haber retrasos que simplemente no puede ajustar.
Como un pequeño aparte, me parece un error común pensar que el correo electrónico es instantáneo. No lo es, al menos no siempre. Puede que no dependa de usted, pero si desea un método para distribuir información de manera efectiva e instantánea , una página web centralizada con contenido actualizado o mensajes instantáneos con algo como Openfire puede ser una buena ruta.
Vamos a jugar un juego...
Como experimento mental con los datos que publicó, imaginemos una situación en la que un lote no puede iniciarse hasta que se complete el último:
Lote 1
1) Los usuarios 8 y 7 responden debido al bajo tráfico de red y las transacciones se completan rápidamente:
14:43:12 Object: TEST dst:[email protected] src: [email protected]
14:43:18 Object: TEST dst:[email protected] src: [email protected]
2) Desafortunadamente, hay un aumento en el tráfico poco después de que se envían los dos primeros elementos y se descarta la transacción del Usuario 6. El servidor de correo decide esperar 5 minutos para volver a intentarlo, pero nuevamente falla a las 14:49. Por lo tanto, espera otros 5 minutos y la transacción finalmente es exitosa (retraso de 10 minutos):
14:54:09 Object: TEST dst:[email protected] src: [email protected]
3) La congestión solo ha empeorado. Ahora hay 4 errores de transacción en intervalos de reintento de 5 minutos para la transacción del Usuario 5 (retraso de 20 minutos):
15:14:09 Object: TEST dst:[email protected] src: [email protected]
Lote 2
4) El lote 1 ha terminado. Según algunas configuraciones, el servidor decide esperar 10 minutos antes de comenzar a procesar el lote 2 a las 15:24.
El servidor de correo intenta realizar una transacción para el correo electrónico del Usuario 4, el primero en el lote 2. Desafortunadamente, el aumento continuo del tráfico ha hecho que las transacciones exitosas sean relativamente imposibles, lo que resulta en otro retraso de 30 minutos (6 intentos fallidos). Esto da como resultado un total de 40 minutos antes de que se pueda enviar el primer correo electrónico en el lote 2:
15:54:09 Object: TEST dst:[email protected] src: [email protected]
5) Afortunadamente, el período ocupado ha terminado y el servidor de correo ahora puede completar el resto de las transacciones de Batch 2 rápidamente:
15:54:09 Object: TEST dst:[email protected] src: [email protected]
15:54:10 Object: TEST dst:[email protected] src: [email protected]
15:54:10 Object: TEST dst:[email protected] src: [email protected]
