Defina primero la pregunta y el destinatario
Un proveedor puede necesitar evidencia para diagnosticar un problema de firma, un alineación desajuste o una discrepancia en los informes. Rara vez necesita todos los informes para cada dominio de la organización. Comience formulando la pregunta exacta, el producto y la cuenta involucrada, el destinatario previsto y qué decisión debería permitir la evidencia. Esto evita una solicitud de “la DMARC “datos” se conviertan en una divulgación innecesariamente amplia.
Confirme que el destinatario es el contacto de ingeniería o soporte autorizado para el servicio correspondiente. Un nombre para mostrar familiar o una solicitud reenviada no es suficiente para establecer que todos los archivos adjuntos deben enviarse allí. La redacción de un paquete es independiente del permiso para transmitirlo. Este artículo describe únicamente la preparación y no autoriza el envío por correo electrónico, carga o uso compartido externo.
Mantenga el alcance vinculado a la ruta y al intervalo afectados. Un proveedor que investiga su propio flujo de trabajo de recibos no debe recibir correo de empleados, marketing u otro tráfico de proveedores no relacionado simplemente porque esas observaciones ocupan el mismo archivo agregado.
Comprenda lo que el informe puede revelar
Informes agregados contienen observaciones técnicas e información de políticas que pueden revelar aspectos de la infraestructura y el tráfico del remitente. RFC 9990 analiza las consideraciones de privacidad para los destinatarios y los datos del informe. Incluso cuando un campo no es el cuerpo de un mensaje, puede que aún sea innecesario para la tarea del proveedor. Trate la minimización como una decisión campo por campo en lugar de asumir que toda la información agregada es inofensiva.
Informes de fallas tener una superficie de exposición separada y potencialmente más detallada debajo RFC 9991. No los incluya con resúmenes agregados bajo una aprobación genérica para "informes". Identifique explícitamente el tipo de informe, el contenido y el propósito del destinatario. Si una pregunta de diagnóstico se puede responder con un resumen más pequeño o un extracto redactado, prefiérelo a un artefacto completo sin procesar. RFC 9990 , sección 7.1 y 7.2; RFC 9991 , secciones 7.1 y 7.2
Construya un mapa de campo de datos antes de la redacción
El mapa de campo debe enumerar cada elemento candidato, por qué es necesario, si es necesario un valor exacto, el tratamiento propuesto y las consecuencias de eliminarlo. Los elementos potenciales incluyen el dominio De origen relevante, el dominio de firma, selector, dominio del sobre, dirección de origen, intervalo de informe, recuento y resultado de la evaluación. Su necesidad depende de la cuestión; No existe un paquete universal que deba enviarse siempre.
Es posible que se necesiten algunas identidades técnicas exactas para diagnosticar la alineación o localizar una configuración específica de la cuenta. Si esos valores no se pueden compartir según el alcance aprobado, explique la limitación del diagnóstico en lugar de reemplazarlos con valores engañosos. Otros identificadores se pueden eliminar o seudonimizar constantemente preservando las relaciones. Mantenga un mapeo privado solo cuando sea necesario y esté autorizado, y no lo incluya en el paquete del proveedor de forma predeterminada.
Elimine filas y dominios no relacionados, direcciones de destinatarios innecesarias, contenido de mensajes, notas internas y secretos. Nunca incluya contraseñas, claves API, tokens de sesión o credenciales en un artefacto de soporte. Revise nombres de archivos, metadatos, capturas de pantalla y contenido oculto de hojas de cálculo, así como texto visible; un párrafo redactado no garantiza que el archivo adjunto se minimice.
Preservar las relaciones diagnósticas
Una muestra de evidencia útil debe conservar la distinción entre resultados de autenticación sin procesar y alineación. Si la pregunta es por qué falló DMARC , reemplazar cada dominio con el mismo marcador de posición puede borrar la relación que el proveedor necesita comprender. Preserve si las identidades son iguales, relacionadas o diferentes, y etiquete claramente los reemplazos sintéticos para que no se confundan con nombres DNS reales para consultar.
Mantenga juntos el intervalo de informes, los campos de resultados relevantes y las notas de alcance. Si solo se comparten las filas seleccionadas, indique que la muestra está filtrada e identifique la regla de selección. No modifique un resultado para que el ejemplo parezca más simple y no dé a entender que un recuento filtrado representa el tráfico total de la organización. Cuando sea necesario, proporcione una explicación concisa del analista junto con los campos retenidos. RFC 9989 , sección 4.4; RFC 9990 , sección 3.1
Hoja de trabajo de aprobación y retención
Prepare un registro de aprobación con destinatario, organización, producto, propósito, archivos o campos exactos, dominio o ruta afectada, intervalo de tiempo, sensibilidad, método de transferencia y decisión de retención. Identifique si el proveedor puede conservar el material únicamente para el caso, utilizarlo para otro propósito o compartirlo posteriormente. No asuma que una relación de soporte general autoriza la reutilización no relacionada o el acceso amplio.
La decisión de retención debe abordar tanto la copia del proveedor como la copia de trabajo de la organización. Registre la duración prevista o el desencadenante de eliminación y quién puede verificar la finalización cuando sea importante. Este es un proceso de gobernanza propuesto, no una afirmación de que un contrato con un proveedor ya proporciona términos específicos. Si los términos disponibles o el acceso del destinatario no están claros, resuélvalo antes de la transmisión.
La aceptación requiere que un revisor compare el paquete final con el mapa de campo aprobado. Se debe comprobar el archivo adjunto real, no simplemente una descripción, para detectar filas no relacionadas, datos ocultos y secretos accidentales. Un destinatario cambiado, un conjunto de datos ampliado o un nuevo propósito deberían desencadenar una revisión renovada en lugar de ser tratados como una continuación inofensiva del mismo recurso compartido.
Paquete de apoyo ficticio para una ruta de firma
Imagine un proveedor de recibos ficticio investigando una situación alineada. DKIM falla. El informe agregado sin procesar de la organización también contiene observaciones de campaña y correo de los empleados. Para este ejemplo no se accedió a ningún informe real o solicitud de proveedor. El paquete propuesto contiene sólo las filas de ruta de recepción relevantes, el intervalo de notificación acotado, las relaciones de identidad pertinentes y una breve explicación de lo que es incierto.
Las filas de empleado y campaña se excluyen porque no responden a la pregunta del proveedor. Si el proveedor necesita un selector o dominio de firma exacto, la organización debe aprobar esos valores para ese destinatario y propósito. Una muestra redactada que los oculte aún puede ser útil para una discusión conceptual, pero no puede presentarse como suficiente para un diagnóstico DNS en vivo.
La aprobación final también registra una decisión de retención específica del caso. No se envía ningún paquete simplemente porque el borrador está completo. Si el proveedor luego solicita muestras de mensajes completos, se trata de una solicitud de contenido nuevo con un perfil de privacidad diferente, especialmente si presenta destinatarios o cuerpos de mensajes. El siguiente paso es una revisión del alcance, no una expansión automática.
Estado de la evidencia y la liberación
El catálogo requiere un mapa de campos de datos y una muestra de evidencia mínima aprobada con una decisión de retención explícita. Este artículo proporciona únicamente un método de preparación y un diseño de paquete ficticio. No se ha aprobado ninguna muestra real, no se ha resuelto ningún destinatario y no se ha verificado ninguna transmisión o eliminación de proveedor.
Las seis puertas de liberación permanecen abiertas. Un revisor calificado debe verificar que la minimización propuesta preserva la pregunta de diagnóstico respetando los límites del destinatario y el propósito. Antes de cualquier acción real, obtener la autorización requerida para los datos reales y el destino. Un borrador preparado de forma segura es un progreso valioso, pero no es evidencia de que el proveedor haya recibido o manipulado algo.