Suprime destinatarios tras un rebote duro o una queja de spam, distingue fallos transitorios, respeta List-Unsubscribe y nunca reintenta la entrega a una dirección suprimida.
Estado del paquete: contexto de referencia listo para revisión humana. El contrato y los escenarios de prueba están completos, pero no se afirma que una implementación adoptante los haya superado.
Decisión
El correo saliente está condicionado por una lista de supresión. Un rebote duro o una queja de spam inserta al destinatario con motivo e ID de evento del proveedor; campañas posteriores y correos transaccionales no deben seleccionar esa dirección excepto a través de un canal documentado de respuesta a abusos. Los fallos transitorios siguen la política de reintentos de la cola de trabajos y no suprimen. Los mensajes comerciales incluyen List-Unsubscribe y, donde se anuncie, un POST de un clic que también escribe supresión. Reintentar una dirección suprimida es un incumplimiento del contrato incluso si la plantilla cambió.
Alcance
- Clasificación de eventos del proveedor como rebote duro, rebote transitorio o queja.
- Escrituras y lecturas de supresión al encolar y desencolar.
- Manejo de List-Unsubscribe y un clic.
- Reproducción de cola envenenada que no puede eludir la lista.
Fuera de este bloque
- Copia y localización de plantillas.
- Puntuación de colocación en bandeja de entrada más allá de actuar sobre quejas.
- Canales SMS o push.
Contrato
- Encolar a una dirección suprimida por
hard-bounceocomplaintes rechazado conrecipient_suppressedy no realiza llamada a la API del proveedor. - Un rebote duro con clase DSN permanente escribe supresión dentro de
apply_within_msy es idempotente sobreprovider_event_id. - Una queja escribe supresión incluso si no se detectó rebote.
- Los fallos transitorios incrementan el estado de reintento y no escriben supresión.
- El correo comercial que requiere perfil incluye
List-Unsubscribey un POST de un clic que autentica un token firmado sin sesión. - La reproducción de cola envenenada verifica supresión después de desencolar y también antes de encolar.
Implementación
Normalizar direcciones con el caso documentado y perfil Unicode. Mapear códigos del proveedor desde una tabla. Respetar RFC 8058: GET no debe desuscribir. Almacenar un hash más dominio de enrutamiento si el programa de privacidad prohíbe direcciones en crudo. La resuscripción tras rebote duro requiere un opt-in confirmado nuevo.
Manejo de fallos
Las firmas de webhook inválidas se descartan sin supresión. Las escrituras de supresión fallidas no deben confirmar el webhook. Los tokens de un clic expirados aún pueden suprimir tras autenticación. Las inundaciones de quejas se aplican por dirección; este bloque no deshabilita el dominio remitente.
Verificación
Medir rechazos al encolar, idempotencia del webhook, mezcla transitorio-versus-duro y reintentos dirigidos a filas suprimidas (deben ser cero). Preparar un POST de List-Unsubscribe. Ejecutar los escenarios empaquetados contra un doble del proveedor.
Los ejemplos con apariencia ejecutable en este paquete son fixtures y contratos de aceptación. Ejecutar
python tools/validate.py desde la raíz de la colección para verificar estructura y metadatos del paquete; luego
implementar y ejecutar los escenarios en el repositorio objetivo.
Suposiciones para adopción
- Nombres y valores numéricos en
example.yamlson un perfil de adopción, no valores universales por defecto. - El equipo adoptante debe mapear actores, clases de datos, vocabulario de errores y propiedad a su sistema.