Michael Haardt wrote:
Usage: notify [":method" string]
[":id" string]
[<":low" / ":normal" / ":high">]
[":message" string]
I miss a sender specification of some kind, like [":from" string], like
we have for vacation.
So you want to distinguish between notifications caused by messages
being delivered into different accounts?
Fine with me, as long as it is optional.
The format of the notification is implementation-defined. However,
all content specified in the notify action, including Sieve actions
taken on the message, SHOULD be included. If errors occurred in
another action they SHOULD be reported in the notification. In
addition, if the notification method does not provide a timestamp,
one SHOULD be appended to the notification. Implementations SHOULD
NOT include extraneous information.
I don't like that, because it means I have to delay sending notifications
until successful delivery of a message, like transferring it to the mail
store or forwarding it to another host.
Based on numerous comments I've updated the paragraph to read:
The format of the notification is implementation-defined and
is also affected by the notification method used (see below).
However, all content specified in the notify action SHOULD be
included. It is RECOMMENDED that a timestamp is included in
the notification. Implementations SHOULD NOT include extraneous
information.
This should eliminate any confusion.
What if the user is over quota
or the remote host is down? That's not a successful delivery. Yet I would
like to get a notification that the mail was seen by the filter.
In my implementation overquota checks are done after Sieve, so
notifications will be always sent.
Anyway, I hope the new text clarifies this.
I guess what I do not like it that notify sounds like DSNs. To me,
it should be just some action. If I decide to send a notification and
then discard the message in order to process mail alarms, I don't need
to have notify tell me the message was discarded.
If the :method tag is not specified, the default
implementation defined notification method is used. The
possible values of this will be site-specific. If an URI schema is
specified that the implementation does not support, the notification
MUST be ignored. An implementation treats this as a warning
condition and execution of the sieve script MUST continue.
As I wrote in another mail, people have a hard time to get phone numbers
right, like not including letters in them. I prefer to generate errors
if that happens. That way they see something is wrong instead of yelling
at the SMS provider.
Ok, the new text reads:
If an URI schema is specified that the implementation does not
support, the notification MUST be ignored.
And later:
If the :method tag contains a supported URI schema, then the URI MUST
be checked for syntactic validity. An invalid URI syntax or an
unsupported URI extension MUST cause an error.
May an implementation choose not to send any notification if no method is
given? I run a bunch of systems without a default notification mechanism.
I am Ok with that, but I would like to hear more opinions.
Alexey