Subject: [Fwd: Re: [Fwd: DISCUSS: draft-ietf-sieve-notify-mailto]]

From: Alexey Melnikov <[email-masked]>
Date: Tue, 02 Dec 2008 11:34:58 +0000

This message didn't get to the archive, so I am forwarding it.

Subject: Re: [Fwd: DISCUSS: draft-ietf-sieve-notify-mailto]
From: [email-masked], [email-masked], [email-masked]
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]
Date: Mon, 01 Dec 2008 14:34:13 -0800 (PST)

> 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