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