Tema: email
-
¿Tras cuántos rebotes suaves, y en qué período, debería quien envía dejar de enviar correo a una dirección?
Pregunta abierta: los códigos de estado ampliados separan los fallos permanentes (5.X.X) de los fallos transitorios persistentes (4.X.X), pero el estándar deja el caso transitorio a la política de quien envía; ¿qué umbrales se han usado en la práctica y qué ocurrió con las tasas de recuperación y con la reputación?
-
Cabeceras List-Unsubscribe y de baja con un clic (RFC 2369 y RFC 8058)
RFC 2369 define cabeceras que permiten a los clientes de correo ofrecer acciones de lista; el «one-click» de RFC 8058 añade una URI HTTPS en List-Unsubscribe más List-Unsubscribe-Post: List-Unsubscribe=One-Click, procesada mediante un POST HTTPS sin redirección y sin pasos adicionales, con ambas cabeceras cubiertas por DKIM. Las directrices de Google exigen a los remitentes masivos que lo admitan.
-
Invitaciones iCalendar: UID, SEQUENCE y cómo gestionar correctamente las zonas horarias
Un evento iCalendar se identifica mediante UID y se revisa mediante SEQUENCE; sus horas pueden ser UTC, hora local con un TZID que remite a un VTIMEZONE incrustado, o flotantes. Usar hora local anclada a una zona para reuniones recurrentes, UTC para eventos puntuales entre husos horarios distintos, y enviar actualizaciones y cancelaciones con el METHOD de iTIP que el cliente receptor espera.
-
Autenticación de correo electrónico: SPF, DKIM y DMARC
SPF enumera los servidores autorizados a enviar correo en nombre de un dominio, DKIM firma los mensajes con una clave del dominio y DMARC indica a los receptores qué hacer cuando ambos fallan y adónde enviar los informes; los tres son registros TXT de DNS que deben conservarse cuando se modifican otros registros.
-
Autenticación de correo con SPF, DKIM y DMARC
SPF (RFC 7208) indica qué servidores pueden enviar correo en nombre de un dominio, DKIM (RFC 6376) firma los mensajes con una clave publicada en el DNS, y DMARC (RFC 7489) define qué hacen los receptores cuando la verificación falla y adónde envían los informes. Los tres son registros TXT del DNS que deben sobrevivir a cualquier cambio de DNS.
-
Envío fiable de correo transaccional: fila outbox, worker, reintentos y claves de idempotencia
No envíes el correo desde el manejador de la petición: registra el mensaje en la misma transacción que el evento de negocio, deja que un worker lo entregue, reintenta con backoff las respuestas transitorias (4yz) y los fallos de conexión, detente ante respuestas permanentes (5yz) y evita duplicados tras una caída con una clave de idempotencia por evento y un Message-ID estable.
-
Las cabeceras de baja con un clic reducen la tasa de quejas por spam frente a un simple enlace en el pie del mensaje
Hipótesis: con la misma lista y el mismo contenido, los mensajes con las cabeceras List-Unsubscribe y List-Unsubscribe-Post de la RFC 8058 reciben menos acciones de «marcar como spam» por mensaje entregado que los que solo incluyen un enlace en el pie, porque el cliente de correo ofrece darse de baja junto al botón de spam; se propone una prueba A/B con asignación aleatoria.
-
Validar direcciones de correo: qué puede y qué no puede decirte una comprobación de sintaxis
RFC 5321 limita la parte local a 64 octetos y una ruta a 256; el estándar HTML usa a propósito una gramática más simple que RFC 5322 para input type=email; las direcciones internacionalizadas requieren SMTPUTF8 de extremo a extremo. Comprueba sintaxis y longitudes, consulta el MX al registrarse, confirma la titularidad con un mensaje y nunca "corrijas" una dirección automáticamente.
-
Estructura MIME de un correo electrónico: multipart/alternative, la parte de texto plano y las codificaciones
Un mensaje con texto y HTML es un multipart/alternative cuyas partes se ordenan de la más simple a la más rica (text/plain primero, text/html al final); los cuerpos con bytes no ASCII usan quoted-printable o base64, y las cabeceras usan encoded-words de RFC 2047. Genera la parte de texto a partir de los mismos datos que el HTML, escapa las variables y respeta los límites de longitud de línea.
-
Gestión de rebotes y quejas: DSN, códigos de estado mejorados y feedback loops
Los rebotes llegan como notificaciones de estado de entrega (DSN) cuyo campo Status es un código mejorado con el formato clase.sujeto.detalle: 5.X.X es permanente y 4.X.X es un fallo transitorio persistente. Las quejas llegan como informes ARF. Analiza ambos, suprime direcciones según la evidencia y conserva los diagnósticos originales.
Legible por máquina: JSON