On Fri, Oct 14, 2005 at 11:38:35AM +0100, Alexey Melnikov wrote:
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.
Some notification methods, like SMS, support the concept of a sender.
I just want to be able to influence that, perhaps even different senders
for the same account. I see some similarity between notify and vacation,
and suggest, as written in section 4.3 of the vacation draft:
Implementations MAY also impose restrictions
on what addresses can specified in a ":from" parameter; it is
suggested that values which fail such a security check simply be
ignored rather than causing the vacation action to fail.
Reading that, shouldn't it be listed under "security considerations"
as well?
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.
Yes, that is very clear.
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.
Same here.
If an URI schema is specified that the implementation does not
support, the notification MUST be ignored.
I still do not particularly like that, but if it is required by
technical reasons, I can live with it. To me, it is odd if a
typo in the URI scheme is ignored, but typos later on cause errors.
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 I add:
A semantically invalid URI may cause an error?
That would allow me to cause errors for phone numbers my implementation
knows to be crap, although they are syntactically valid.
Michael