email – ¿Es una buena idea reducir el tiempo de entrega de correo electrónico?

Pregunta:

Ejecutamos un servidor de correo electrónico para algunos clientes y recientemente nos hemos encontrado con un pequeño dilema.

Tuvimos un usuario que envió un correo electrónico a una dirección de correo electrónico incorrecta. Desafortunadamente, el dominio especificado incorrectamente existía. No tenía registros MX y el registro A del dominio fue a un servidor que no hablaba SMTP. Por lo tanto, el servidor de correo electrónico intentó realizar la entrega y no tuvo éxito porque no se estaba ejecutando ningún servidor de correo electrónico.

Por esa razón, nuestro servidor de correo electrónico, totalmente de acuerdo con SMTP RFC, intentó volver a enviarlo en el transcurso de cinco días y finalmente se rindió y envió un aviso al remitente después de 5 días de entrega fallida.

La sección 4.5.4.1 de RFC5321 (Protocolo simple de transferencia de correo) dice:

Los reintentos continúan hasta que se transmite el mensaje o el remitente se rinde; el tiempo de abandono generalmente debe ser de al menos 4-5 días.

Por lo tanto, el servidor de correo en su configuración predeterminada, en este caso, ha operado de acuerdo con el RFC, lo que significa que un usuario que especifique la dirección de correo electrónico incorrecta en este caso no recibirá notificación de eso excepto cinco días después.

En este punto, mi jefe ha preguntado si sería posible reducir el tiempo de entrega a algo más corto, digamos 1 día. Su razonamiento es que es mejor que se notifique al usuario antes de la falta de entrega y que el usuario puede intentar la reenvío en una fecha posterior o la entrega a través de un canal alternativo. Suena como algo razonable, pero en general desconfío de realizar cualquier tipo de cambio de configuración que contradiga lo que está en el RFC.

¿Existe alguna razón no obvia por la que sería una mala idea reducir el tiempo de abandono a 24 horas, más allá de simplemente decir "la RFC dice lo contrario"?

Además, ¿qué hacen los proveedores de correo electrónico más grandes (Google, Microsofts, AOL y Yahoos) en este escenario?

Respuesta:

¿Por qué no debería dejar de enviar correos electrónicos después de un día? Una buena razón son los fines de semana .

El correo electrónico no es ahora, y nunca lo fue, particularmente confiable . En los primeros días de Internet, la década de 1980, era completamente posible que el correo electrónico tardara un par de días en llegar a su destino, con algunos enlaces de red que no eran 24×7, en lugar de costosas llamadas de discado de larga distancia (en ese entonces costaba por minuto para llamar a dos ciudades de distancia, sin importar el costo de una llamada de Sydney a Los Ángeles), o incluso por radioaficionado. Como resultado, podría llevar un tiempo entregar el correo electrónico y los protocolos tuvieron que hacer frente a conexiones poco fiables y de medio tiempo. Lo hacen muy bien, pero incluso entonces, el correo podría retrasarse o perderse.

Ciertamente, hoy en día, el correo electrónico tiene una ilusión de confiabilidad, aunque solo sea porque los transportes subyacentes son más confiables, y muchas personas desinformadas (como la mayoría de nuestros usuarios) tienen la expectativa de que es confiable, pero esa expectativa no coincide con la realidad. Sin un cambio significativo en los protocolos de entrega de correo electrónico, que probablemente nunca sucederá, el correo electrónico, como todo lo creado por humanos, siempre será menos del 100% perfecto.

A veces, los administradores de sistemas nos aprovechamos de eso.

Por ejemplo, en una oficina donde todo el mundo está allí solo de lunes a viernes, puedo tener una interrupción del correo electrónico que dure todo el fin de semana si es necesario. Por supuesto, prácticamente nunca es necesario estar fuera tanto tiempo, pero he tenido que tener el correo electrónico inactivo durante más de 24 horas en casos excepcionales.

En tal caso, si se da por vencido después de 24 horas, es posible que el correo electrónico enviado el viernes por la tarde no llegue a su destinatario. El remitente no se enterará hasta el lunes por la mañana, pero si lo hubiera seguido intentando, el destinatario lo habría recibido el lunes por la mañana.

Además, es muy importante establecer adecuadamente las expectativas del usuario. El hecho de que el correo electrónico de Internet no es y nunca será 100% confiable debe entenderse claramente, incluso cuando nos gusta pensar que lo es.

La RFC dice que debe seguir intentándolo, precisamente porque las cosas van mal, y se pretende que el correo se entregue eventualmente, si es posible, pero en algún momento debe darse por vencido. Podría estar bien reducir esto a tres días. Siempre pensé que cinco días era demasiado tiempo para esperar la entrega de la mayoría de los mensajes en Internet 24×7.


En cuanto a su servidor de correo dado:

Postfix puede notificar a los remitentes cuando un mensaje de correo electrónico se ha retrasado, pero esta función está desactivada de forma predeterminada. Esta advertencia debería ser suficiente para que sus usuarios sepan que algo podría haber salido mal, como una dirección de correo electrónico mal escrita, y llegará mucho antes de las 24 horas que su jefe ha propuesto.

Para habilitarlo, configuredelay_warning_time en el valor deseado en main.cf

delay_warning_time=4h

A partir de la versión 3.0, Postfix también puede notificar a esos mismos remitentes cuando finalmente se entregan los mensajes retrasados. Esto también está desactivado de forma predeterminada, ya que puede generar muchas notificaciones. Pero si quieres esto, permitan confirm_delay_cleared en main.cf .

confirm_delay_cleared=yes

Leave a Comment

Your email address will not be published.

Scroll to Top

istanbul avukat

-

web tasarım