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
example.com, 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
notifications.
?
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.
?
Ok.
Lisa