Haga de la interoperabilidad una comparación reproducible
Una declaración que un receptor admite actualizada DMARC no es un resultado de interoperabilidad. La pregunta útil es si las implementaciones identificadas, dadas las entradas equivalentes controladas, producen el descubrimiento esperado. alineación, políticas y comportamiento de presentación de informes. Una comparación debe preservar esas etapas en lugar de reducir el experimento a si dos mensajes llegaron a una bandeja de entrada.
Comience con un catálogo de casos versionado y un propietario de prueba designado. Registre el software o servicio del receptor, la configuración, la información de la versión accesible y cualquier incógnita. Un servicio administrado no puede revelar su versión de implementación; esa limitación pertenece a la matriz. No reemplace la información que falta con un reclamo de adopción derivado de un anuncio de producto o una marca de tiempo de un informe reciente.
Congele las entradas que podrían cambiar el resultado.
Para cada caso, conserve los bytes del mensaje, el sobre y las suposiciones de la fuente de conexión, los datos DNS relevantes, el tiempo de observación y el perfil de configuración. Haga que las diferencias entre dos ejecuciones de prueba sean intencionales y visibles. Si una ruta modifica un mensaje firmado o utiliza un dominio de sobre diferente, la comparación ya no se trata únicamente del comportamiento de implementación DMARC .
Utilice únicamente dominios autorizados, receptores y mensajes no confidenciales controlados. Mantenga los casos de diseño ficticios separados de los elementos ejecutables y las muestras de entrega reales. Escriba el resultado esperado y su referencia de especificación antes de ejecutar una prueba; de lo contrario, un resultado sorprendente puede describirse retroactivamente como esperado. Un caso no ejecutado debe permanecer explícitamente como no ejecutado y no recibir una aprobación inferida de la documentación.
El inventario de remitentes también importa. Incluir rutas legítimas representativas, especialmente servicios indirectos y periódicos, al decidir si la cobertura del laboratorio es relevante para un cambio de producción. Un caso protocolario puede ser correcto omitiendo el flujo de negocio que realmente se verá afectado.
Compare el descubrimiento y la alineación antes de la disposición
RFC 9989 sección 4.10 describe el comportamiento de recorrido de árbol DNS , mientras que las implementaciones anteriores pueden utilizar su método de descubrimiento heredado compatible. Los casos deben cubrir una política explícita de dominio de autor y acuerdos de respaldo controlados. Agregar casos de políticas de subdominios aplicables y dominios inexistentes solo con condiciones DNS claramente especificadas; una etiqueta que diga subdominio no es suficiente para definir la política esperada.
Capture el registro seleccionado y los identificadores autenticados utilizados para la alineación. Luego registre la política p, sp o np seleccionada y el estado de prueba. RFC 9989 sección 4.4 define la relación de alineación. Paso SPF o DKIM para una identidad no relacionada no debe etiquetarse erróneamente como DMARC exitoso simplemente porque un receptor finalmente aceptó el mensaje.
Finalmente registre las anulaciones locales y la disposición real como resultados separados. El filtrado de contenido, el enrutamiento y las decisiones locales pueden crear resultados de entrega diferentes incluso cuando el cálculo DMARC ordinario coincide. Diagnostique la etapa de diferenciación más temprana en lugar de atribuir cada diferencia de buzón al descubrimiento de políticas.
Incluir la transición de prueba sin asumir equivalencia
Un caso útil compara cómo se procesan las implementaciones identificadas. un récord que contiene p=reject t=y. Bajo RFC 9989 sección 4.7, el tratamiento de prueba para un mensaje fallido es un nivel inferior: cuarentena. Una implementación heredada que no reconoce t puede seguir una lógica compatible diferente. Esta es una cuestión de compatibilidad que se espera medir, no una razón para implementar ese registro como un interruptor de seguridad universal.
Separe los casos históricos de pct de los casos t. Un plan que alguna vez solicitó muestreo no debe declararse compatible simplemente porque un receptor actualizado ignora el control anterior sin cometer un error de sintaxis. El efecto empresarial previsto, el mecanismo especificado y el resultado observado necesitan sus propios campos.
Conserve los casos de etiquetas desconocidas, políticas faltantes y entradas mal formadas dentro de un alcance de prueba controlado. No utilice un dominio de producción como destino experimental para registros deliberadamente ambiguos. El diseño de la prueba en sí debe identificar los requisitos relevantes de aprobación y recuperación antes de cualquier ejecución operativa.
Informes de prueba como una capacidad separada
RFC 9990 define la estructura del informe agregado, incluido el método_descubrimiento opcional y el contexto de prueba. Un informe que contenga esos campos puede respaldar una observación sobre ese informe; un campo opcional omitido no demuestra un comportamiento heredado. Conserve el informe sin procesar y el perfil del analizador, porque un consumidor puede perder información incluso cuando el receptor la generó correctamente.
Los períodos de informe pueden incluir transiciones de políticas, por lo que un agregado no siempre es una transcripción de una única política congelada. Alinee la ventana de tiempo de la comparación y la evidencia de la fuente antes de usar los recuentos para explicar un mensaje en particular. La deduplicación y la compatibilidad de esquemas pertenecen al plan de prueba de informes en lugar de estar ocultas en un panel.
La notificación de fallos es otra dimensión independiente. RFC 9991 deja la generación sujeta a la voluntad del receptor y a restricciones de privacidad. No informe de falla no es prueba suficiente de una prueba de interoperabilidad fallida. Registre si los informes fueron solicitados, respaldados, autorizados, recibidos e interpretables sin recopilar contenido de mensaje innecesario.
Matriz ficticia sin celdas de resultados observadas.
Una hoja de trabajo ficticia nombra al Receptor A como referencia semántica actual y al Receptor B como perfil heredado. A ambos se les asigna el mismo mensaje inventado y la misma instantánea DNS para p=reject; t=y caso. La columna de política esperada para A se deriva de la especificación. La implementación de B y todos los resultados reales aún requieren evidencia; ningún producto se supone que se comporta como la etiqueta.
La matriz planificada también incluye un control alineado directo, un caso de dominio autenticado no relacionado, un caso de descubrimiento alternativo y casos de formato agregado. Ninguna celda de ejecución permanece sin ejecutarse. Esto hace que la hoja de trabajo sea una preparación útil sin prueba de conformidad de fabricación ni adopción del receptor.
Preservar el requisito de liberación exacto
La puerta de evidencia original es: Mantener una matriz de interoperabilidad versionada con casos de entrada idénticos y resultados observados completos. El requisito de puesta en servicio es: Validar las especificaciones primarias actuales y conservar un ejemplo trabajado antes de redactar el borrador. La matriz ficticia conservada no satisface ni la observación en vivo ni la preparación para la producción. La evidencia de implementación nombrada, los resultados controlados, la revisión humana de las PYME, la aprobación del lanzamiento comercial y la autorización de publicación permanecen abiertas. Este manuscrito no ha realizado ninguna prueba de receptor, cambio DNS ni transmisión de mensajes.