[Top] [All Lists]

Re: WGLC for Sieve Notify has ended

2007-01-22 04:49:56

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?

Also, if you feel that the two examples you gave above should be specifically mentioned, I can add them to the text.

- 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.

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


- 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>