This message didn't get to the archive, so I am forwarding it.
--- Begin Message ---
It seems like the draft should include a way for a recipricant of these
notifies to tell the server to stop sending them. If someone accidentally fat
fingers a phone number for a SMS notify in a sieve script, how will the poor
users getting all the SMS ever stop them?
I'm afraid this time I have to agree with Cullen - such a mechanism is indeed
needed and would be very useful.
Kristin Hubner, Chris Newman and I tossed around various approaches and this is
what we came up with.
(1) Include a cancellation token and cancellation address as a parameter on
the auto-submitted header field.
(2) If the recipient gets the message in error, send a message containing the
cancellation parameter and a reason for cancellation to the cancellation
address.
(3) Upon receipt of the cancellation request, the receiving system validates
the cancellation token (exactly how this is done would be
implemenation-specific). The message is silently dropped if the
validation fails.
(4) If validation succeeds the system records a tuple of the sieve owner,
the destination address who doesn't want to get any more of these
messages, the reason, and the current time. A response is also sent to the
requestor saying the cancellation is effect.
(5) The system periodically scans or otherwise prunes its cancellation list,
removing cancellation requests that have timed out. The timeout period
is implementation specific but we'll need to decide on a minimum, which
probably should be something like a week.
(6) An implementation may optionally include a timeout value as part of the
cancellation token. If a valid cancellation requests comes in for a
timed out cancellation token a response saying it wasn't honored should
be sent.
Notify mailto processing then needs to be changed to check the cancellation
list. An error occurs if the sieve owner and notification destination match an
entry on the list. The error should include the reason given by the recipient
for not wanting the notification any more. As always, a sieve error converts
the script into a keep and notifies the sieve owner in an
implementation-specific way.
We think this a reasonable technical solution, although of course this is far
from a precise specification.
The issue here is that this isn't a problem specific to notify mailto: and
coming up with a specific solution for this one case is inappropriate. Just as
one exmaple, such a mechanism could be used to deal with errant MTA-level
autoforwards and Sieve redirects. It is therefore inappropriate to put this in
the notify mailto document. It needs to be defined more generally, and I for
one would be happy to work on defining this as a more general mechanism.
We note in passing that implementation of this capability is actually quite
similar to implementation of Sieve vacation's duplication supression. In our
implementation at least we believe the same underlying facility can be used for
both.
We therefore think that the way to handle this is to define such a mechanism in
a completely new specification, one which can potentially be
referenced/included by any future facility that sends messages automatically.
And given how many existing facilities can cause this problem, notify mailto:
isn't going to create much more of a problem. So we believe the right thing to
do is get started on this work right away but not hold up notify mailto: for
it.
Ned, Kristin, and Chris
--- End Message ---