Un registro generado es un artefacto de decisión.
A Registro DMARC El generador puede formatear una política propuesta, pero no puede decidir qué remitentes legítimos tiene la organización, qué riesgo comercial acepta o si un destino de informes está autorizado. El resultado debe explicar cada opción de política y los supuestos detrás de ella. Una cadena copiable sin esas decisiones puede fomentar la publicación de una política sintácticamente plausible que no se ajuste a los flujos de correo reales de la organización.
RFC 9989 define el formato y mecanismo de la política actual. Este artículo propone requisitos para un generador y una revisión de resultados anotados. No afirma que EmailAuth implemente un generador, produzca un registro listo para producción o cambie DNS . Los casos de prueba originales requeridos y la evidencia operativa permanecen separados del marco explicativo.
Establecer el dominio y la propiedad de la política
Registre el dominio para el cual se está preparando la política, el propietario de la empresa, el propietario de la publicación DNS y los flujos de trabajo de envío legítimos dentro del alcance. Distinga el nombre exacto del propietario donde se publicaría una política de las identidades de dominio utilizadas por los remitentes. Un generador no debe elegir silenciosamente un dominio principal o secundario basándose en una etiqueta de visualización o en un límite organizacional asumido.
El descubrimiento de políticas actuales incluye la Caminata por el árbol DNS descrito por RFC 9989. La anotación del generador debe explicar el alcance previsto y cualquier suposición relacionada con la herencia que deba revisarse, en lugar de prometer que un récord afecta sólo a la dirección que el usuario escribió. El comportamiento aplicable real depende de la implementación del estándar y del receptor. Durante este trabajo no se consultó ninguna jerarquía de dominio ni política existente.
Explicar la política solicitada y la preparación.
La política solicitada expresa la preferencia de evaluación del propietario del dominio según el protocolo; no es una garantía de la disposición final del receptor ni una declaración de que todo remitente legítimo está preparado. Antes de recomendar la aplicación de la ley, solicite una revisión de preparación remitente por remitente y una decisión autorizada sobre las fallas restantes. Un generador puede presentar opciones y consecuencias, pero no debería inventar la aprobación empresarial detrás de ellas.
Explicar alineación opciones separadas de la severidad de las políticas. El dominio visible From, autenticado SPF identidad y DKIM El dominio de firma tiene relaciones definidas en DMARC. La alineación estricta y laxa no son meras etiquetas para una seguridad general más fuerte o más débil; sus implicaciones operativas dependen de la estructura de dominio de la organización y de los servicios de envío. Preservar la justificación seleccionada y las dependencias no resueltas en el resultado anotado.
Conservar la versión actual y la semántica de etiquetas.
RFC 9989 todavía especifica el valor de versión DMARC1 que distingue entre mayúsculas y minúsculas. Un generador no debe anunciar un nuevo documento de estándares como un cambio a DMARC2. La posición y el valor requeridos de la etiqueta de versión deben validarse de acuerdo con el formato actual. Las etiquetas desconocidas deben ser ignoradas por el procesamiento del protocolo según la definición formal, por lo que la herramienta debe distinguir una advertencia de etiqueta no compatible de una regla inventada de que cada etiqueta desconocida invalida toda la política.
El Apéndice A.6 explica la eliminación de pct y la introducción de t con valores de y y n. Un generador actual no debería llevar adelante un control deslizante de porcentaje obsoleto como si fuera un control normativo actual, ni asumir que reemplazar cada porcentaje histórico con t es una migración universal segura. Debe documentar el estándar al que se dirige, la semántica de prueba exacta y las preguntas de compatibilidad que quedan para el entorno previsto.
Trate los destinos de informes como destinatarios aprobados
RFC 9990 define informes agregados y verificación de destinos externos. Un generador debe explicar que publicar una solicitud de informe y recibir informes son pasos diferentes. Debe identificar el destinatario propuesto, el propósito de los datos y si existe la autorización de destino externo aplicable. No infiera autorización simplemente porque un usuario pegó una dirección en un formulario.
Este artículo no proporciona una dirección de informes, no publica un registro de autorización ni envía datos a un tercero. Un resultado propuesto debe utilizar marcadores de posición claramente no operativos hasta que se apruebe un destino. La anotación también debe indicar que la disponibilidad del informe depende de los receptores y la entrega, por lo que incluir un URI no garantiza observaciones completas. Las opciones de informe de fallas, si se ofrecen, requieren su propia especificación compatible y revisión de privacidad en lugar de agruparse casualmente en una configuración de informe agregado.
Explicar el manejo de registros existentes y duplicados.
Un generador debe preguntar cómo se relaciona la política propuesta con el estado publicado existente. Producir una segunda política candidata para el mismo propietario puede generar un resultado diferente al de reemplazar un registro existente aprobado. Por lo tanto, el resultado debe describir la diferencia exacta prevista y preservar el material de restauración, no simplemente decir agregar esto. registro TXT. Los datos TXT existentes no relacionados no deben eliminarse como efecto secundario de la generación de políticas.
RFC 1035 define la estructura del registro TXT . Varias cadenas dentro de un registro TXT no son lo mismo que varios registros de políticas. La anotación y las pruebas deben preservar esa distinción para que la visualización del editor no engañe al operador. Aquí no se inspeccionó ningún estado DNS existente; el manejo duplicado sigue siendo un requisito de prueba propuesto más que un resultado verificado.
Una hoja de trabajo anotada
Cree una hoja de trabajo con el dominio de la política, el propietario de la publicación, el registro propuesto, el significado de cada etiqueta, la justificación seleccionada, la evidencia de requisitos previos y el propietario de la aprobación. Agregue referencia del estado existente, diferencia exacta prevista, autorización del destinatario de informes, limitaciones de compatibilidad, plan de verificación y criterios de reversión. Mantenga la sintaxis generada separada del estado de aprobación y publicación. Un formulario completo no debería implicar automáticamente permiso para realizar un cambio en vivo.
El conjunto de accesorios requerido debe incluir un caso válido positivo, una versión no válida o casos de formato requerido, candidatos de política duplicados y comportamiento de etiquetas no admitidas. Indique los resultados esperados de la norma actual y las reglas de presentación del producto por separado. Conserve la versión del generador, la entrada de prueba y la salida observada cuando se ejecuten pruebas autorizadas posteriormente. Este borrador no ha generado ni evaluado esos accesorios y no hace ningún reclamo de conformidad con la implementación.
Diagnóstico ficticio: un control deslizante de porcentaje oculta la decisión
Un equipo ficticio utiliza un formulario de política antiguo con un control deslizante de porcentaje y asume que seleccionar un número menor hace que cualquier cambio de cumplimiento sea seguro. El revisor pregunta qué estándar implementa el formulario, cuál es la preparación legítima del remitente de la organización y cómo se comportará el resultado propuesto en los receptores relevantes. La apariencia del control no responde a esas preguntas.
La respuesta propuesta es obtener el comportamiento actual vinculado a los estándares, documentar la decisión política y verificar un plan de cambio exacto en lugar de traducir mecánicamente el control deslizante a otra etiqueta. Ningún generador o proveedor real es acusado de este comportamiento. El ejercicio es ficticio, no se genera ningún registro, no se modifica DNS ni se realiza ninguna prueba del receptor. Ilustra por qué la lógica de las políticas debe permanecer visible junto con la sintaxis.
Requerir evidencia antes de llamar a la salida lista
Un resultado útil del generador indica qué insumos se proporcionaron, qué supuestos permanecen y qué debe suceder antes de la publicación. Puede ayudar a un propietario calificado a tomar una decisión coherente sin afirmar que el texto formateado establece una aplicación segura. La autoridad final recae en el proceso de cambio técnico y comercial aprobado.
El catálogo requiere un registro anotado y casos de prueba de etiquetas positivas, no válidas, duplicadas y no compatibles. Esos artefactos originales permanecen abiertos. La revisión de especialistas humanos, la aplicabilidad de las fuentes, las rutas de producción, la accesibilidad y la autorización del propietario también permanecen abiertas. Este borrador proporciona una hoja de trabajo propuesta y un diagnóstico ficticio, no una política lista para publicar, pruebas completadas o características verificadas de la herramienta EmailAuth .