On Tue, 2005-09-27 at 13:50 +0100, Alexey Melnikov wrote:
Abstract:
This draft describes an extension to the Sieve mail filtering
language that allows users to give specific preferences for
- notification of Sieve actions.
+ notification of mail delivery.
Sieve notify can also be used to notify about Sieve actions executed for
a message, so the original text is better in this respect.
The document as written is not quite clear how this has to be done, though.
I suggest:
[...] that allows users to give specific rules for how and when
notifications should be sent when mail is received.
One thought I have is to have separate documents describing how
different notification schemas should be handled, e.g. a separate
document for SMS, another one for XMPP, etc.
I think it would be good if the notify document described at least one
method. it seems to me that the amount of explanation needed for SMS
and XMPP would be very little, and not worthy of a separate document.
there is no need to go into protocol specifics, IMHO, a simple mapping
for where the message should go seems sufficient.
3.1 Notify Action
In
addition, if the notification method does not provide a timestamp,
one SHOULD be appended to the notification.
Why bother with this? While I agree it might be a sensible idea, I
was surprised to see it as a SHOULD, I guess it's not a MUST
though :o/
"appended" indicates to me that it should be part of the message, and
that just doesn't seem right. most of the notification methods will
have a timestamp field which can be used, and if they don't and won't
"pollute" the message with a textual timestamp, well, tough cookies for
the users of that notification method.
I can even lowercase SHOULD here.
I don't think that's appropriate. either it should stay with capital
letters, or it should be removed.
<<Open issue: the previous version of this draft has defined the two
variables that can't be currently represented:
$text$ - the first text/* part
$text[n]$ - the first n bytes of the first text/* part
>>
I'd like to drop both of these, and wait for other extensions used with
VARIABLES to allow the behaviour.
Yes, this will need an extension to variables.
well, you need "body".
if body :text :matches "*" {
set "text" "${1}";
}
and to do the $text[n]$ bit you need "regex" as well:
if body :text :regex ".{120}" {
set "text" "${1}";
}
one general issue which I think should be specified in 3.1, is how to
handle charsets when the notification method doesn't support full UTF-8.
something like: "Characters in the message which can't be represented by
the notification method SHOULD be replaced with a symbol indicating an
unknown character, e.g., a question mark."
5. Security Consideration
Is there additional risk of mail loops when using this extension?
Yes, if you use mailto: URI schema. Or any other notification method
that can be getawayed to mail.
But this is not an issue specific to Sieve notify.
if the mailto: schema is described in this document, there should be a
reference to RFC 3834 ("Recommendations for Automatic Responses to
Electronic Mail.") to cover this.
--
Kjetil T.