> 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.
It seems to me that SHOULD has the right semantics here. Of course there are
plenty of other considerations, including situations where validity cannot be
accessed, notification mechanisms that either don't have the concept of an
author or which embody it as something other than an email address. But SHOULD
provides enough leeway that such cases can be dealt with without incompliance.
> > - 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.
Some time back we introduced the idea of an "owner email address" in our sieve
implementation to deal with this and related issues. However, there are also
cases where you cannot use such an address even if you have it: One such is
when the notification relates to a message arriving inside of a highly secure
environment. We have customers using notify in such cases to inform some
outside address that they need to check their secure mail, and one of the rules
is that the notification has to come from a generic address - not even the
recipient's address can be exposed. (My assumption is that sometimes the
address of a recipient conveys some information as to what the person does, and
revealing that is a no-no. Or maybe they's no real risk and they're being
paranoid. Whatever - rules is rules.)
> > 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.
This seems reasonable to me as well.
Ned