Resumen

  • La revisión 09 del grupo DKIM, fechada el 1 de noviembre, añade un registro de política de dominio que faltaba en la versión del 27 de octubre.
  • Un dominio padre puede publicar strict para impedir que la firma de un subdominio vuelva «Authentic» un From que usa el nombre del padre. Sin ese indicador, el borrador permite esa correspondencia.
  • El registro se busca en _domainkey del padre concreto y no se hereda. Un fallo temporal de DNS produce TEMPERROR; varias políticas válidas, PERMERROR.

El proveedor recibió una habitación y apareció en la puerta principal

Una empresa delega mail.example.com para que un proveedor envíe correo. La llave de firma del subdominio delegado queda en manos del proveedor. La versión 09 de DKIM2 permite que esa firma también haga «Authentic» el From visible de example.com, salvo que el padre marque otra cosa. El texto mantiene esa práctica de DKIM1 como regla inicial de su propia prueba. La versión 08 no tenía este nuevo registro ni la comprobación de ascenso.

La salida está en el DNS del propio padre. La sección 3.8 coloca un TXT en _domainkey.example.com, empezando por v=DKIM1. Entre sus indicadores f= puede figurar strict: los subdominios dejan de estar autorizados a autenticar un From que use example.com. Si falta el indicador, si falta f= o si no hay registro, el borrador los considera autorizados para esta prueba. La decisión descrita afecta al resultado DKIM2 propuesto, no es una afirmación sobre mensajes ya entregados mediante DKIM1.

La sección 7 explica el recorrido. Primero se compara el dominio de From con el dominio d= de la firma relevante. Si no coincide, se invierte la comparación. Ese segundo intento puede subir desde el subdominio firmante hacia el padre del From. El strict del padre corta precisamente esa ruta. Una firma hecha por el dominio padre exacto no necesita ese segundo intento. La política tampoco viaja por el árbol DNS: cada dominio gobierna su propio nombre.

La lectura DNS tiene consecuencias. Dos políticas válidas llevan a PERMERROR; un fallo temporal de consulta lleva a TEMPERROR. La ficha IETF mantiene el texto como Internet-Draft de grupo, I-D Exists. Las fuentes consultadas no aportan una implementación interoperable de esta regla nueva.