[Top] [All Lists]

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

2008-07-22 06:26:04

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.