Resumen

  • La sección 6.5 de la revisión 30 de EMAILCORE exige que los receptores SMTP puedan aceptar correo con y sin confidencialidad del transporte, pero aclara que la actuación de cada extremo en una circunstancia concreta depende de su política local. Sigue siendo un Internet-Draft, en «AD Followup», no un RFC.
  • La revisión 29 decía que los receptores no debían exigir confidencialidad a los remitentes. La redacción nueva ha provocado preguntas públicas sobre el alcance de una obligación de implementación. Las intervenciones de septiembre no equivalen a una decisión final del IESG.

Un administrador puede configurar un servidor privado para cortar cualquier intercambio sin TLS. El programa que ejecuta ese servidor, sin embargo, quizá conserve un modo de recibir mensajes no protegidos. Esa posibilidad no obliga al administrador a activarla. Parece una diferencia pequeña hasta que un requisito con la palabra «MUST» intenta describir qué se espera de todos los receptores SMTP.

En draft-ietf-emailcore-as-30, el primer mandato de la sección 6.5 afecta al envío: utilizar confidencialidad si está disponible y el receptor la acepta. El segundo recae sobre la recepción: poder aceptar mensajes con o sin ella. Acto seguido, el texto reserva la conducta en una situación determinada a la política local. En la edición 29, el segundo mandato se expresaba como una prohibición de exigir confidencialidad al remitente. El historial del propio borrador indica que la sección de seguridad se reescribió durante la revisión del IESG. Por tanto, no estamos ante una novedad de mecanismo criptográfico, sino ante una variación de a quién obliga y sobre qué objeto.

La situación procesal es parte de la noticia. Datatracker seguía mostrando la revisión 30 como borrador activo y en seguimiento del director de área. En la papeleta todavía aparecían objeciones DISCUSS, presentadas originalmente frente a la edición anterior y referidas a asuntos distintos. John Klensin explicó el 18 de septiembre a Roman Danyliw que una parte de su respuesta era personal y aún no había sido revisada por el grupo de trabajo.

El 28 de septiembre Eric Rescorla sostuvo que, si el requisito de capacidad no agrega nada, debería eliminarse; Rob Sayre defendió la importancia de separar lo que implementa un producto de lo que decide quien lo opera. Son posiciones públicas identificables, no un acuerdo ya ratificado.

También hay que separar esta conversación de RFC 3207. Esa especificación antigua sobre STARTTLS no permite que un servidor SMTP referenciado públicamente lo exija para la entrega local, mientras admite la exigencia en un servidor que no esté referenciado públicamente. Es una regla delimitada por el tipo de servidor y por STARTTLS. No transforma todos los MX en servicios obligados a aceptar cualquier mensaje sin protección, ni decide qué modos deben permanecer disponibles dentro de un programa receptor.

El remitente de un mensaje dispone, además, de un instrumento distinto. RFC 8689 define REQUIRETLS para exigir confidencialidad a un mensaje en los saltos compatibles y admitir que la entrega falle antes que continuar en claro. BTW ya ha tratado ese mecanismo desde el punto de vista del mensaje. No responde al debate de EMAILCORE sobre la capacidad genérica de recepción. Mezclar ambas piezas produciría una falsa contradicción: una trata una decisión asociada a un mensaje; la otra, la base técnica de un receptor y su relación con las políticas de operación.

La discusión importa porque los borradores de aplicabilidad acaban orientando pruebas de conformidad, compras y documentación de fabricantes. Si se interpreta «debe poder» como «debe permitir siempre», se desplaza una decisión del operador sin que el texto lo diga. Si, por evitar esa confusión, se elimina cualquier vía de recepción sin cifrado del software, una excepción futura podría exigir cambiar de versión en vez de modificar una política. El expediente no mide cuántas instalaciones sufrirían uno u otro problema. Tampoco demuestra un fallo real de entrega causado por el borrador.

La pregunta abierta es dónde debe fijar la norma una capacidad común y dónde debe dejar intacta la opción local.

Fuentes