Resumen
- RFC 9671 permite que Sieve procese adjuntos de calendario, pero obliga a detener datos malformados, representaciones contradictorias, mensajes maliciosos y adjuntos incrustados peligrosos.
- SPF, DKIM, DMARC y S/MIME aportan señales de confianza delimitadas; ninguna demuestra por sí sola la intención actual de la persona organizadora.
- El resultado
updatedagrupa actualización, cancelación y borrado, por lo que una operación responsable debe releer el estado final del calendario.
La cancelación llegó desde el dominio correcto. DKIM validó. DMARC quedó alineado. El UID coincidía con una reunión real y el mensaje usaba el método esperado. El sistema eliminó la cita antes de que nadie leyera el correo.
Horas después apareció otra posibilidad: la cuenta de envío era legítima, pero una integración autorizada había emitido una cancelación equivocada. Todas las comprobaciones técnicas podían ser verdaderas y la voluntad atribuida al organizador, falsa.
RFC 9671 no comete el error de igualar esas capas. Describe processcalendar, una acción Sieve capaz de interpretar datos de calendario dentro de correo MIME y de añadir, cambiar o retirar objetos. En sus consideraciones de seguridad cita firmas válidas, SPF, DKIM y DMARC como factores de confianza. Dice “puede depender”, no “queda demostrado”.
La autenticación responde preguntas más pequeñas
SPF relaciona el cliente SMTP observado con la política publicada por un dominio. DKIM permite comprobar una firma sobre partes seleccionadas del mensaje bajo un dominio firmante. DMARC evalúa alineación y política desde la perspectiva del receptor. S/MIME firma el mensaje bajo una cadena de certificados y reglas de identidad.
Son controles importantes. Precisamente por eso conviene preservar su significado. Un pase de DKIM no es una declaración jurada de la persona cuyo nombre figura en la invitación. La alineación DMARC no demuestra que una aplicación haya elegido el UID correcto. Una firma S/MIME exige además interpretar el certificado, el firmante y la autoridad que la organización reconoce.
Entre “el mensaje conserva una relación técnica válida con este dominio” y “esta persona quiso cancelar este compromiso ahora” hay decisiones de cuenta, aplicación, delegación y negocio. Un sistema autorizado puede equivocarse. Una cuenta puede ser tomada. Un mensaje válido puede llegar fuera del contexto en que debía operar.
El principio de las capas de realidad ayuda a no confundirlas. La capa simbólica dice que una verificación pasó. La capa operativa muestra qué servicio produjo el correo, qué política lo admitió y qué calendario cambió. El nombre del control no sustituye a su resultado observable.
Antes de confiar, hay que saber qué se está procesando
RFC 9671 exige ignorar datos de calendario malformados. Si el mensaje contiene varias partes MIME calendarias, hay que demostrar que son semánticamente equivalentes. Si difieren, no se procesa ninguna; si coinciden, solo se aplica una representación.
La regla evita que una parte visible y otra procesable conduzcan a resultados distintos. También establece que processcalendar no puede cambiar el estado de participación del destinatario. Aceptar, rechazar o marcar asistencia pertenece a otra decisión humana o de producto.
El estándar recomienda quitar alarmas antes de aplicar los datos. Sin esa precaución, un evento puede disparar avisos no deseados, repetirse y propagarse a varios dispositivos. El resultado de la acción no informa si ese saneamiento ocurrió. Hay que observar las alarmas finales.
Los adjuntos incrustados abren otra frontera. Deben decodificarse y analizarse; si alguno es malicioso, los datos de calendario no se deben procesar. La gramática válida de una invitación no vuelve inocuo el contenido que porta.
La dirección de destino tampoco equivale a autorización
Sin :allowpublic, el mensaje debe estar bien formado según iTIP y una dirección del destinatario debe coincidir con la finalidad de la operación. Para REPLY se compara ORGANIZER; para REQUEST, CANCEL y ADD, una propiedad ATTENDEE. La dirección puede proceder de la cuenta, del destinatario final de sobre o de :addresses.
Registrar esa procedencia es esencial. Una dirección visible, un alias corporativo y el destinatario final no son el mismo hecho. Añadir un alias a :addresses amplía lo que el script puede considerar propio del usuario. Si esa decisión no queda versionada, una futura investigación verá la coincidencia pero no sabrá bajo qué política se aceptó.
:organizers permite exigir que ORGANIZER aparezca en una lista externa y que el mensaje sea iTIP válido. Cuando se omite, la acción no valida esa propiedad. Cuando se usa, la coincidencia demuestra pertenencia a una lista, no intención personal. La lista sigue necesitando propietario, alcance y fecha de vigencia.
El resultado operativo empieza donde termina updated
Con la extensión Variables, :outcome puede contener no_action, added, updated o error. La palabra updated incluye una modificación de contenido, una cancelación o una eliminación. :reason puede quedar vacío cuando no exista una explicación disponible.
Esta compresión es razonable para ramificar un filtro. No es suficiente para afirmar qué ocurrió con el evento. :deletecancelled solicita que una cancelación elimine el objeto; sin esa opción, debe conservarse marcado como cancelado. Ambas rutas caben dentro de updated, y la eliminación expresada por :deletecancelled es una recomendación, no una observación.
El recibo útil une dos tramos. El primero conserva el ID del mensaje, destinatario final, versión del script, controles de correo, partes MIME, equivalencia, método iTIP, UID, ORGANIZER, ATTENDEE, lista usada, opciones y calendario seleccionado. El segundo consulta el calendario: existencia del UID, calendario real, revisión, STATUS, participantes, alarmas y resultado de adjuntos.
También hay que registrar el correo por separado. processcalendar no cancela la conservación implícita de Sieve. El evento puede cambiar y el mensaje quedar guardado. Borrar uno no demuestra el destino del otro.
La guía de CalConnect muestra por qué esta trazabilidad importa. El abuso de calendario puede situar eventos en cualquier fecha, añadir recurrencias y disparar avisos en varios clientes. El daño no termina cuando finaliza el filtro. Una afirmación responsable debe llegar hasta el estado que verá la persona.
RFC 9671 ofrece una especificación inicial mínima: una acción interoperable, controles claros y resultados compactos. La organización conserva la libertad de adoptar políticas locales. Esa libertad exige no esconder la decisión local detrás de la palabra “autenticado”.
Sources
- RFC 9671
- RFC 9671 en texto
- RFC 9671 en XML
- Erratas del RFC 9671
- Información del RFC 9671
- Historial IETF del RFC 9671
- Sieve, RFC 5228
- Pruebas de spam y virus en Sieve, RFC 5235
- iCalendar, RFC 5545
- iTIP, RFC 5546
- iMIP, RFC 6047
- Listas externas de Sieve, RFC 6134
- DKIM, RFC 6376
- SPF, RFC 7208
- DMARC, RFC 7489
- S/MIME 4.0, RFC 8551
- Registro IANA de extensiones Sieve
- Guía de CalConnect contra abuso de calendario
- Especificación inicial mínima
- Capas de realidad
- Primacía del código en ejecución
Informe para miembros
Contexto ampliado del perfil
Inicia sesión con el nivel de membresía adecuado para desbloquear el informe completo y las notas de las fuentes.
Solo para Strategic Circle
Strategic Circle
Abierto a todos los lectores. Desbloquea informes de perfil después de unirte e iniciar sesión.
Únete a Strategic CircleSolo para Leadership Alliance
Leadership Alliance
Para propietarios y directivos cualificados de activos de propiedad intelectual; inicia sesión para desbloquear los informes de la alianza.
Unirse a Leadership Alliance

