[Top] [All Lists]

Re: WGLC for Sieve Notify has ended

2007-01-26 14:44:26

responses in-line...

On Jan 21, 2007, at 6:22 AM, Alexey Melnikov wrote:

Lisa Dusseault wrote:

I think we're going to need a bit more language in the sieve- notify draft about sending from authorized or unauthorized from addresses, as well as about sending to people who do not want to receive notifications, and throttling. I'm not sure exactly what needs to be said, however. - Something about how implementations SHOULD restrict the from address to allow only appropriate mailboxes? SHOULD restrict the from address so that other domains aren't caused to be spoofed?

Here is the text I've added (taken from the vacation draft and reworded):

   In order to minimize/prevent forgery of the author value,
implementations MAY impose restrictions on what values can specified
   in a ":from" parameter; it is suggested that values which fail
   such a validity check simply be ignored rather than causing
   the notify action to fail.

Do you want to upgrade the MAY to SHOULD?

My individual opinion would be for a SHOULD but I'm not sure what other considerations hold.

- If the recipient of a sieve notify mail doesn't want those notifications, what recourse do they have?

I think this problem is already present in email.

Yes, obviously. But I wonder how often notifications will be sent from a system address for simplicity. E.g. all notifications might come from "notification(_at_)example(_dot_)com" for the IMAP server for, regardless of whose SIEVE rule generated the notification. Then it becomes harder for the recipient to filter which notifications they do and don't want, and a little different from ordinary email.

Servers SHOULD add a  "cancel" link to each notify mail... ?

How about the following text (I've reworded and extended Dilyan's proposal):

Notifications SHOULD includes means to identify/track its origin, in order to allow a recipient to stop notifications or find out how to contact the sender. This requirement is to help tracking a misconfigured or abusive origin of


Yes, and I think this addresses my above concern.

- If the notification frequency is high, servers SHOULD throttle notifications (and if so what error to produce)? Disable the rule?

Considering there is already some text about "not retrying notification indefinitely", I think it would be Ok to just drop notifications silently. I also think that throttling should be a MAY. So how about the following text:

  If there are errors sending the notification, the Sieve interpreter
  SHOULD ignore the notification and not retry indefinitely.
  The Sieve interpreter MAY throttle notifications; if it does,
  a request to send a notification can be silently ignored.
  Documents describing notification methods SHOULD describe how
  retries, throttling, duplicate suppression (if any), etc. are
  to be handled by implementations.




<Prev in Thread] Current Thread [Next in Thread>