Este es un mensaje de notificación, no de error. Y significa que en que los primeros tres intentos de envío de nuestro servidor al servidor destino, este último lo está rechazando por alguna causa que desconocemos y está fuera del alcance y soporte de Alveni Cloud. En algunas ocasiones es por reglas de Greylisting activado en el servidor del destinatario.
Alveni Cloud genera esta notificación para que el cliente sepa que si no llega su mail de inmediato no es un tema interno sino del servidor destino que al menos en tres ocasiones lo rechazó.
En la mayoría de los casos, lo más probable es que uno de los siguientes intentos de entrega de nuestro servidor, se logre realizar exitosamente. Si esto sucede, el remitente ya no recibirá más notificaciones ni mensajes de "no entregado". Si no se entrega después de todos nuestros intentos, entonces recibirá una notificación de "rebote".
Recibir estas notificaciones no es común y es causa de retrasos en la entrega de mails a los destinatarios.
Causas.
La(s) causa(s) del bloqueo inicial se desconoce(n) y está(n) fuera del alcance y soporte de Alveni Cloud. Esto se tiene que resolver con el proveedor de hosting o administrador de email del dominio destino.
Sin embargo para apoyarlo, le indicamos las posibles causas:
- El dominio destino cuenta con alguna política que se tenga configurada en su servidor de Greylisting que no esté de acuerdo a los parámetros "normales" de todos los servidores de la industria. Y por lo tanto está deteniendo los primeros intentos de entrega del mail en cuestión.
- El dominio destino cuenta con alguna política en su firewall, antispam, u otros mecanismos de procesamiento de los emails que bloquea parcial o totalmente el(los) mensaje(s) en cuestión o hasta el usuario y/o dominio del remitente.
- El dominio destino está en un servidor con disponibilidad intermitente o alta carga. Esto significa que puede no recibir los emails debido a que no está disponible (por conectividad u otro factor) o que tiene una carga excesiva de trabajo y por lo mismo no lo acepta.
Solución.
Los servidores de Alveni Cloud cumplen con los estándares de reintentos de entrega de mails marcados por IEFT, por lo que en la mayoría de los casos, aunque se reciba esa notificación inicialmente, el mensaje se entrega exitosamente en alguno de los siguientes intentos que se tienen configurados en nuestro sistema de email. De lo contrario, el remitente recibirá un mensaje en donde se indica que su email no fue recibido por el destinatario. De suceder esto último, representaría un "error" de entrega y habría que buscar la solución a dicho incidente.
De parte del administrador de email del dominio del destinatario, tendría que buscar una solución de acuerdo a sus configuraciones de su sistema y/o a la disponibilidad del servidor en cuestión. Esto está fuera del alcance de Alveni Cloud y en ningún caso tenemos la obligación de involucrarnos en la búsqueda de la solución.
Más información.
Alveni / Alveni Cloud tiene una configuración de intervalos de reintento que cumple y supera los requerimientos de IETF: 5, 15, 30, 60, 90, 120, 240, 480, 960, 1440, 2880 minutos después del intento inicial.
IETF retry requirements call for "shall retry for up to 4 days", but they do not specify the frequency of the retry attempts. This goes back to the days of e-mail actually being two different programs: sendmail and readmail. When the first e-mail experiments were developed by DARPA and the universities authorized to work on the projects, the networks were not constantly connected and the e-mail servers connected every few days to transfer files, send and receive messages.
Based on the demands of today's power e-mail users, the sooner a message is delivered, the better. In reality however, technology does break down and is not always repaired immediately. Attempting to retry delivery too quickly might not allow a message to be delivered at all, so most ISPs have opted to try several times within the first couple of hours and then retry at longer intervals to allow the receiving ISP time to resolve non-receipt issues.
Nuestros servidores cumplen con los estándares de reintentos de entrega de mails marcados por IEFT.
IETF retry requirements call for “shall retry for up to 4 days”, but they do not specify the frequency of the retry attempts. This goes back to the days of e-mail actually being two different programs: sendmail and readmail. When the first e-mail experiments were developed by DARPA and the universities authorized to work on the projects, the networks were not constantly connected and the e-mail servers connected every few days to transfer files, send and receive messages.
Based on the demands of today’s power e-mail users, the sooner a message is delivered, the better. In reality however, technology does break down and is not always repaired immediately. Attempting to retry delivery too quickly might not allow a message to be delivered at all, so most ISPs have opted to try several times within the first couple of hours and then retry at longer intervals to allow the receiving ISP time to resolve non-receipt issues.