Resumen

  • RFC 5233 añadió :user y :detail a las comparaciones de direcciones de Sieve, pero no normalizó un separador ni una convención universal de direcciones con etiquetas.
  • El sistema de correo receptor conserva la autoridad sobre la codificación local; el sobre to puede retener un detalle que no aparece en una cabecera visible.

El signo era local; el límite era el contrato

Un detalle añadido a una dirección puede enviar un mensaje a una carpeta, identificar una suscripción a una lista o distinguir un buzón de voz. El signo más es una manera conocida de expresarlo, pero solo un ejemplo. Publicado en enero de 2008, RFC 5233 dio a Sieve dos partes de dirección adicionales — :user y :detail— para comparar, no una gramática mundial para todas las direcciones.

La parte local se interpreta en el sistema de correo que la recibe. RFC 5233 muestra el detalle después del usuario con + y también antes, con . Si la secuencia separadora aparece más de una vez, el modo de dividir es específico de la implementación y normalmente depende del formato del sistema de correo. La implementación debe ajustarse a la codificación que ese sistema utiliza o permite; el mecanismo para definirla o consultarla queda fuera del RFC. Un filtro no puede deducir que + significa «detalle» porque otro proveedor lo use así.

Si la dirección no contiene un componente de detalle codificado, :user representa toda la parte local, equivalente a :localpart. En ese caso, :detail no coincide con ninguna clave solicitada. Si sí existe un detalle pero está vacío, el valor es la cadena vacía. Así se distingue un componente ausente de otro presente sin contenido.

El RFC separa además la fuente de la dirección. La prueba address consulta cabeceras estructuradas del mensaje; la prueba opcional envelope consulta datos del transporte. Cuando se quiere ordenar correo según la dirección que hizo que llegara a un destinatario concreto, RFC 5233 prefiere en general el sobre to. Las listas, los alias y los dominios virtuales pueden hacer que ese sobre sea el único lugar donde sobreviva el detalle propio del destinatario. Aplicar el formato local a una dirección ajena —por ejemplo, la del remitente— puede producir resultados incoherentes o incorrectos.

La extensión sustituyó el texto anterior de RFC 3598. Sus notas de cambio generalizaron la descripción de la codificación y añadieron las cautelas sobre el sobre y las direcciones ajenas. IANA registra la capacidad subaddress, pero ese registro no garantiza que todos los sistemas acepten una forma determinada. Sieve puede comparar una interpretación local que el sistema le proporciona; no la crea ni demuestra cómo se aprovisionó un buzón.

Fuentes