Se usa para permitir que las notificaciones se envíen por correo electrónico. Define como se usan URIs(Identificador Uniforme de Recursos), los URI son cadenas de caracteres que identifican a un recurso sin equivocarse, para generar notificaciones por correo electrónico.
Al enviar un correo electrónico se manda una notificación al destinatario para indicar un mensaje entrante.
Sieve es un lenguaje de programación que se puede utilizar para crear filtros de correo electrónico. Debe su creación al Proyecto CMU Cyrus, creadores de Ciro servidor IMAP.
El lenguaje no está ligado a ningún sistema operativo o arquitectura electrónica. Se requiere el uso de RFC 2822 compatibles con los mensajes. La versión actual de la especificación se describe en el RFC 5228, publicado en enero de 2008.
Sieve difiere de los lenguajes de programación tradicionales ya que es altamente limitado. A pesar de las extensiones que se han ideado para extender el lenguaje para incluir variables y, hasta cierto punto, los bucles, el lenguaje sigue siendo muy limitado, y por lo tanto no apto para el funcionamiento de los programas ideados por el usuario como parte del sistema de correo.
También hay un número significativo de las restricciones a la gramática de la lengua, con el fin de reducir la complejidad de analizar el lenguaje, pero el lenguaje también es compatible con el uso de múltiples métodos de comparación de cadenas localizadas, y es totalmente compatible con Unicode.
Los scripts Sieve pueden ser generados por un editor de interfaz gráfica de usuario basada en reglas o se pueden introducir directamente utilizando un editor de texto.
El protocolo ManageSieve (definido en el RFC 5804) permite a los usuarios gestionar sus scripts Sieve en un servidor remoto. Los servidores de correo con los usuarios locales pueden permitir que los scripts se almacenan en, por ejemplo un archivo.
El mecanismo de notificación usa el estándar mailto URI como se especifica en [mailto], contiene campos de cabecera que son llamados encabezados URI para poderlos distinguir de los "encabezados de los mensajes".
Prueba "notify_method_capability"
Esta prueba notify_method_capability online puede devolver "sí" o "no" sólo si el procesador Sieve puede determinar con certeza si o no los destinatarios del mensaje de notificación en línea se han autentificado de lo contrario, la prueba devuelve "tal vez" para este método.
El tag ":from" anula el remitente por defecto de la notificación del mensaje. El remitente aquí significa "from" header que se usa en el RFC5322 que dice el campo "from:" especifica el autor del mensaje, es decir, el buzón de correo de la persona o sistema responsable para la escritura del mensaje. El campo "Sender:" especifica el buzón del agente responsable de la transmisión real del mensaje. Por ejemplo, si una secretaria fuera a enviar un mensaje para otra persona, el buzón de correo del secretario aparecería en el "Sender:" y el buzón de correo del autor real aparecería en el campo "De:".
El tag ": importance" no tiene un significado especial para este mecanismo de notificación, y no hay ninguna restricción en su uso.
Se usa el valor de ":importance" para establecer una prioridad o importancia en el mensaje de notificación (quizás un indicación visual, o tal vez haciendo uso de no estándares pero comúnmente utilizado en los encabezados de los mensajes).
Tag de mensaje ": message"
El valor de esta etiqueta, si está presente, se utiliza como el sujeto de el mensaje de notificación, y anula todos los demás mecanismos de la determinación del sujeto, su valor no debe ser vacío, pero también debe ser razonable para no tener un valor muy largo.
Debido a que este método de notificación utiliza un sistema de almacenamiento para la entrega del mensaje de notificación, el procesador Sieve no debe tener la necesidad de notificaciones de reintento. Por lo tanto, para las implementaciones de este método es conveniente utilizar los mecanismos normales para la presentación de los mensajes SMTP y para volver a intentar la comunicación inicial. Una vez que la notificación del mensaje se envía, las implementaciones NO DEBEN volver a enviarlo, ya que es probable que resulte en múltiples notificaciones, y aumenta la peligro de bucles de mensajes.
El envío de una notificación es comparable con reenviando de correos al destinatario de la notificación. Se debe tener cuidado al enviar correo de forma automática, para asegurar que la información confidencial no se envía en un entorno inseguro.
El envío automatizado de mensajes de correo electrónico expone el sistema de correo a bucles, a que puedan causar problemas de funcionamiento. Las implementaciones de esta especificación deberá protegerse contra bucles de correo. Otras mitigaciones de bucles de correo involucra algunos tipos de limitaciones.
En mi opinión personal creo que el número de notificaciones generado por un único usuario podría estar limitado a no más de, digamos, 30 en un período de 60 minutos. Por supuesto, esta técnica presenta sus propios problemas, en que la tasa real de límite debe ser seleccionado cuidadosamente, para permitir situaciones más legítimos en el ambiente dado.
La intervención humana podría ser necesaria para volver a habilitar notificaciones que se han deshabilitado debido a que un bucle se ha detectado, o poner fin a un ciclo muy lento. Deben estar disponibles mecanismos administrativos para manejar este tipo de situaciones. Podría ser mejor que se abarcara en este tema también los aspectos de las respuestas automáticas y que así no hubiera otro separado que es el RFC 3834.
RFC 5436
RFC 3834
mailto
Bien; 10.
ResponderEliminar