Re: I-D Action:draft-ietf-sieve-notify-mailto-08.txt

> I'm looking for consensus on one of these:
>
> 1. Using Auto-Submitted to avoid loops -- and, therefore, the risk of 
> loops if we send notifications for auto-submitted messages -- is 
> sufficiently important that the current "MUST NOT" text should stay.
> 2. The use cases for notifications on auto-submitted messages are 
> sufficiently important that the text should be changed.  [Please suggest 
> new text, in this case.]
> 3. "SHOULD NOT" is an acceptable compromise.  The current "MUST NOT" 
> should be changed to "SHOULD NOT", with some added text to explain the 
> danger very clearly.  [In this case, you can suggest text, or I'll craft 
> it.]
> Let's try to get clear consensus on this.  I propose that in the event of 
> no clear consensus, we have to go with (3).
I'm with option 3 just now.  My reasons, some of which have already been 
touched on:
I think the intent of sieve-notify was to do things like notify mobile 
devices, or at least devices with some limited resources that the user has 
more immediate access to.  Re-scanning the abstract seems to back this up. 
As such I think those devices are very unlikely to auto-reply to anything, 
or if they do, then it may not be until they make a connection and receive 
the notification, which would lead for a very slow mail loop.  But then what 
I think the intent of sieve-notify is, and what it'll get used for can of 
course be completely different.
Sieve-notify-mailto is therefore in some ways a poor fit with sieve-notify, 
cos the target could very very easily be capable and willing to auto-reply, 
in which case mail loops become much more likely and dangerous (hence we are 
having this discussion).  If the purpose of sieve-notify-mailto is to hide 
sensitive information from the inbound message, then I wonder if it's better 
handled by modifying redirect rather than piggy backing onto sieve-notify, 
then we're not adding to the existing mail loop concerns created by the use 
of redirect, and standard loop prevention mechanisms apply.  I think the use 
cases proposed to make folks vote for option 2 would be better handled by an 
alternative notification mechanism like SMS where no auto-reply is expected, 
and therefore there's a greatly reduced loop risk.  Option 1/3 both try to 
create a "no auto-repsonse" mimicing what is expected by the other 
sieve-notify mechanisms that it was originally designed for.
So this whole discussion has made me very reluctant to go anywhere near 
implementing sieve-notify-mailto, rather sticking to SMS notifications and 
redirect if I can.
Nigel