This looks cool! Some random questions/suggestions from a bystander:
* I would be happier with two separate variables for the RFC 2822
"display name" and the "address". Having both the name and the mail
address would fill up my entire cell phone display. Maybe keep
$from$ as is, and add $from-address$ and $from-name$.
Q: Is it intended to exclude legacy address forms by using the term
"display name"? Perhaps no parsing of From: was intended. I.e.:
foo(_at_)bar (foo bar) rather than "foo bar" <foo(_at_)bar>.
* Are $subject$, $text$ etc QP/CTE-decoded?
* Security consideration additions:
The risk of creating mail loops must be considered, many instant
messaging systems (e.g. ICQ) have capabilities to forward the
notification by Internet Mail if you're not online. Unless somehow
prevented, this might easily cause huge workload for the servers
involved.
* Is the draft really copyright 1999? :) There are some control
characters (^M) in it as well. Also perhaps update RFC 82{1,2} ->
RFC 282{1,2}.
Wolfgang Segmuller <whs(_at_)watson(_dot_)ibm(_dot_)com> writes:
Abstract
Users go to great lengths to be notified as quickly as possible that
they have received new mail. Most of these methods involve polling
to check for new messages periodically. A push method handled by the
final delivery agent gives users quicker notifications and saves
server resources. This document does not specify the notification
method but is expected that using existing instant messaging
infrastructure such as Zephyr, ICQ, or SMS messages will be popular.
This draft describes an extension to the Sieve mail filtering
language that allows users to give specific preferences for
notification of Sieve actions.
http://www.ietf.org/internet-drafts/draft-martin-sieve-notify-01.txt
Wolfgang Segmuller