ietf-mta-filters
[Top] [All Lists]

Re: Updated Sieve notification draft

2005-10-14 03:55:57

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