Subject: MIME loops: Extracting attachment to disk and replacing it with an URL

From: Alexey Melnikov <[email-masked]>
Date: Fri, 18 Apr 2008 15:04:32 +0100

One of our customers would like to extract big attachments from 
messages, put them on an FTP/web server and replace the original 
attachment part with some text and an URL about where the message can be 
found. (This is somewhat similar to what Eudora mail client can do.) The 
reason for this is to avoid sending big messages of an expensive 
satellite link, especially in case the recipient might not want to view 
some big attachments anyway.

It occurred to me that Sieve "replace" from 
draft-ietf-sieve-mime-loop-04.txt can almost do that. The only thing 
missing is constructing an URL, which will have an  
implementation/deployment specific format. One could user Sieve 
variables to construct text in the replace action, but only if the exact 
URL format is known in advance.

So, do people think that a variant of the replace action is reasonable? 
Should there be a new ":url" option?

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Sun, 20 Apr 2008 11:37:06 +0200

Alexey Melnikov writes:
> variables to construct text in the replace action, but only if the 
> exact URL format is known in advance.

Could you elaborate?

> So, do people think that a variant of the replace action is 
> reasonable? Should there be a new ":url" option?

:url doesn't make me feel very good. I'd have many problems getting that right.

Arnt

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 20 Apr 2008 17:14:53 +0100

>> exact URL format is known in advance.

Elaborate on how this can be done with Sieve variables, or elaborate on 
extracting attachements in general?

> :url doesn't make me feel very good. I'd have many problems getting 

To clarify: I was just thinking about adding a flag to the replace 
action, so that the action can generate and insert a unique URL. I was 
not proposing to pass an URL to the replace action.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 21 Apr 2008 14:46:47 +0200

Alexey Melnikov <[email-masked]>
> extracting attachements in general?

How it would be done, the role of :url, and why :url makes this
easier/possible.

Arnt

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 21 Apr 2008 20:50:05 +0100

>How it would be done, the role of :url, and why :url makes this
Ok, imagine that I receive in my mailbox a multipart/mixed message with 
some text/plain and a big pdf attachment.
The pdf attachment might look like this:

=====================
Content-Type: application/pdf;

 name="Sieve-Ned.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="Sieve-Ned.pdf"

JVBERi0xLjMKJcTl8uXrp/Og0MTGCjIgMCBvYmoKPDwgL0xlbmd0aCA0IDAgUiAvRmlsdGVy
IC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeNqNkj9vwjAQxXd/ijfSAdf2Of6zlpaxEkrUzhEE
 [...]

=======================

I want my Sieve script to extract the attachment and put it on an FTP 
server that my mail server trusts.
I want to write a Sieve script (or rather a piece of it), for example:

replace :url text:
Sender sent you a big PDF. If you really want to read it, look here:
.
;

And this would generate a replacement text/plain body part, something like:

=====================
Content-Type: text/plain

Sender sent you a big PDF. If you really want to read it, look here:
<ftp://my.trusted.ftp.example.com/extracted/alexey.melnikov/24U3219IR123E.PDF>

=======================

(Name of the extracted pdf was generated in a way to guaranty filename 
uniqueness.)

Does this make more sense?

---

From: Tony Hansen <[email-masked]>
Date: Thu, 01 May 2008 01:56:59 -0400

While I can see the utility of such an extension, I would not want to
burden the MIME loops spec for replace with it.

	Tony

> The pdf attachment might look like this:

Date: Thu, 01 May 2008 01:56:59 -0400
From: Tony Hansen <[email-masked]>
To: [email-masked]
Subject: Re: MIME loops: Extracting attachment to disk and replacing it with an URL
Sender: [email-masked]

While I can see the utility of such an extension, I would not want to
burden the MIME loops spec for replace with it.

	Tony

> The pdf attachment might look like this:

To: IETF-Announce <[email-masked]>
From: The IESG <[email-masked]>
Subject: Last Call: draft-ietf-sieve-editheader (Sieve Email Filtering:  Editheader Extension) to Proposed Standard 
Reply-to: [email-masked]
CC: <[email-masked]>
Date: Wed, 30 Apr 2008 15:09:55 -0700 (PDT)
Sender: [email-masked]

The IESG has received a request from the Sieve Mail Filtering Language WG
 
(sieve) to consider the following document:

- 'Sieve Email Filtering: Editheader Extension '
   <draft-ietf-sieve-editheader-11.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
[email-masked] mailing lists by 2008-05-14. Exceptionally, 
comments may be sent to [email-masked] instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-sieve-editheader-11.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=12765&rfc_flag=0

Date: Wed, 23 Apr 2008 12:04:38 +0100
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: WGLC on IMAP Sieve (draft-ietf-lemonade-imap-sieve)
Sender: [email-masked]

While this is a Lemonade WG document, this document is of relevance to 
the Sieve WG mailing list and should be reviewed here.

So please review 
<http://www.ietf.org/internet-drafts/draft-ietf-lemonade-imap-sieve-05.txt> 
before May 5th.

Thanks,
Alexey

Date: Wed, 23 Apr 2008 09:32:26 +0100
From: Alexey Melnikov <[email-masked]>
To: Michael Haardt <[email-masked]>
CC: [email-masked]
Subject: Re: Comments on draft-ietf-sieve-notify-mailto-07.txt
Sender: [email-masked]

Michael Haardt wrote:

>>>4. We currently say MUST NOT notify if an Auto-Submitted header field 
>>>exists (apart from "no").  We had an inconclusive thread going with a 
>>>suggestion to change that.  What's the consensus?  If we're to change 
>>>it, what should we change it to, given that it's critical to our 
>>>loop-prevention story?
>>>
>>I am weakly in favor of keeping the current logic. I find your argument 
>>about using redirect in this case to be convincing.
>>
>I like the current logic, too.  It is possible to write a Sieve rule that
>redirects messages with "Auto-Submitted:" (not containing "no"), should
>that really be desired.  Should anybody suggest to do so automatically,
>please add an option to disable that behaviour in your suggestion.
>
I was thinking about this as well.

>>Which reminded me of another question: should we describe how to handle "?cc=..."?
>>    
>>
>Yes. I suggest to add this right after the section about the envelope
>sender:
>
>  The envelope recipient(s) of the notification message SHOULD be set to
>  the address(es) specified in the URI (including any URI headers where
>  the hname is "to" or "cc")
>
>Additionally, change:
>
>  The "To:" header field SHOULD be set to the address(es) specified in
>  the URI (including any URI headers where the hname is "to").
>  
>
I like that.

Date: Tue, 22 Apr 2008 10:47:24 +0200
To: [email-masked]
Subject: Re: editheader interaction with mailto notifications
From: Michael Haardt <[email-masked]>
Sender: [email-masked]

> > So, Auto-Submitted really isn't a good field to use for loop control.
>
> I concur.  Also, as a "notification" is a different best from an "auto  
> response", so use of auto-submitted seems a bit wrong.
> It seems appropriate to use another mechanism for notification loop  
> detection.

>From RFC 3834:

   The purpose of the Auto-Submitted header field is to indicate that
   the message was originated by an automatic process, or an automatic
   responder, rather than by a human; and to facilitate automatic
   filtering of messages from signal paths for which automatically
   generated messages and automatic responses are not desirable.

Notifications originate by an automatic process, not by a human.  We
use this field as intended.

One can argue about using it for loop control.  If somebody is on
vacation, his Sieve script will not respond to automatically generated
alarms and the role account used as sender of these alarms is not
notified about the recipient being away, despite expecting them, as he
would get notified if the recipient mailbox overflowed.  We decided loop
control using widely implemented mechanisms is more important than minor
gripes about missing responses for "vacation".  To me, the same reason
applies here.

Michael

Date: Tue, 22 Apr 2008 10:29:16 +0200
To: [email-masked]
Subject: Re: Comments on draft-ietf-sieve-notify-mailto-07.txt
From: Michael Haardt <[email-masked]>
Sender: [email-masked]

> > 4. We currently say MUST NOT notify if an Auto-Submitted header field 
> > exists (apart from "no").  We had an inconclusive thread going with a 
> > suggestion to change that.  What's the consensus?  If we're to change 
> > it, what should we change it to, given that it's critical to our 
> > loop-prevention story?
>
> I am weakly in favor of keeping the current logic. I find your argument 
> about using redirect in this case to be convincing.

I like the current logic, too.  It is possible to write a Sieve rule that
redirects messages with "Auto-Submitted:" (not containing "no"), should
that really be desired.  Should anybody suggest to to do automatically,
please add an option to disable that behaviour in your suggestion.

> Which reminded me of another question: should we describe how to handle "?cc=..."?

Yes. I suggest to add this right after the section about the envelope
sender:

  The envelope recipient(s) of the notification message SHOULD be set to
  the address(es) specified in the URI (including any URI headers where
  the hname is "to" or "cc")

Additionally, change:

  The "To:" header field SHOULD be set to the address(es) specified in
  the URI (including any URI headers where the hname is "to").

Michael

Date: Tue, 22 Apr 2008 10:08:25 +0200
To: [email-masked]
Subject: Re: Comments on draft-ietf-sieve-notify-mailto-07.txt
From: Michael Haardt <[email-masked]>
Sender: [email-masked]

> 2. Do we have a decision about copying Received lines?  I think we've 
> reversed ourselves, and no longer want to copy them from the original 
> message.  Does that mean:
> a. ...the spec should be changed from MAY copy to SHOULD NOT copy or 
> MUST NOT copy?  If so, which?
> b. ...the spec can remain as it is, with MAY (not SHOULD nor MUST)?
> c. ...the spec should say that you can do anything you please?

By now, I suggest not to say anything about "Received:" at all and I am
sorry about having had that idea in the beginning.  The notification
message simply did not originate at the described path at the given
time, and spam filters could drop it for forged headers.

> 3. What did we decide for the value on the Auto-Submitted header?  I 
> still have it as "Sieve-Notify".  Do we want to change it to 
> "Auto-Notification"?  Something else?

I suggest "auto-notified", like "auto-generated" and "auto-replied".

Michael

Date: Tue, 22 Apr 2008 09:52:37 +0200
To: [email-masked]
Subject: Re: [Fwd: Re: [secdir] secdir review of draft-ietf-sieve-notify-mailto-07.txt]
From: Michael Haardt <[email-masked]>
Sender: [email-masked]

> I agree that the envelope-to is the best choice if the application
> hasn't been configured to use a fixed address.  But I also think that
> having the only choice for a fixed address be a system-wide one isn't
> fine-grained enough.  So maybe instead of "the address of the owner
> of the Sieve script", more like:
>
>   - an email address associated with notification messages sent on
>     behalf of the email-address receiving the message;
>
> and it's up to the implementation how that association is made, or
> whether it's made at all.  One could actually interpret that to cover a
> system-wide address, as well, maybe with some slight fiddling, so that
> the other choice (the "email address associated with the notification
> system") could be dropped.

How about that?

   If ":from" is not specified or is not valid, the envelope sender of
   the notification message SHOULD be set to an email address associated
   with the recipient or the notification system, at the discretion of
   the implementation (common choices are the final envelope recipient
   or a fixed, system-wide sender).

Widen it once more and I suggest "... SHOULD be set." (no more ;)

Michael

Date: Mon, 21 Apr 2008 20:50:05 +0100
From: Alexey Melnikov <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
CC: [email-masked]
Subject: Re: MIME loops: Extracting attachment to disk and replacing it with an URL
Sender: [email-masked]

=====================

 name="Sieve-Ned.pdf"

=======================

replace :url text:

=====================
Content-Type: text/plain

=======================

Cc: [email-masked]
From: Kurt Zeilenga <[email-masked]>
To: "Mark E. Mallett" <[email-masked]>
Subject: Re: editheader interaction with mailto notifications
Date: Mon, 21 Apr 2008 09:22:13 -0700
Sender: [email-masked]

On Apr 19, 2008, at 11:43 AM, Mark E. Mallett wrote:

> So, Auto-Submitted really isn't a good field to use for loop control.

I concur.  Also, as a "notification" is a different best from an "auto  
response", so use of auto-submitted seems a bit wrong.
It seems appropriate to use another mechanism for notification loop  
detection.

-- Kurt

Date: Mon, 21 Apr 2008 14:46:47 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]
Subject: Re: MIME loops: Extracting attachment to disk and replacing it with an URL
Sender: [email-masked]

Arnt

Date: Sun, 20 Apr 2008 22:42:39 +0100
From: Alexey Melnikov <[email-masked]>
To: Kjetil Torgrim Homme <[email-masked]>
CC: Barry Leiba <[email-masked]>, [email-masked]
Subject: Re: Comments on draft-ietf-sieve-notify-mailto-07.txt
Sender: [email-masked]

Kjetil Torgrim Homme wrote:

>On Fri, 2008-04-18 at 22:49 +0100, Alexey Melnikov wrote:
>  
>
>>   Notification message:
>>
>>      Received: from mail.example.com by mail.example.org
>>        for <[email-masked]>; Wed, 7 Dec 2005 05:08:02 -0500
>>      Received: from hobbies.example.com by mail.example.com
>>        for <[email-masked]>; Wed, 7 Dec 2005 02:00:26 -0800
>>      Date: Wed, 7 Dec 2005 05:08:55 -0500
>>      Message-ID: <[email-masked]>
>>      Auto-Submitted: sieve-notify; owner-email="[email-masked]"
>>      From: [email-masked]
>>      To: [email-masked]
>>      To: [email-masked]
>>      Subject: From Knitting list: A new sweater
>>    
>>
>
>note, multiple To-headers is not allowed by 2822.
>  
>
Fine :-). Make it:

      To: [email-masked], [email-masked]

Date: Sun, 20 Apr 2008 17:14:53 +0100
From: Alexey Melnikov <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
CC: [email-masked]
Subject: Re: MIME loops: Extracting attachment to disk and replacing it with an URL
Sender: [email-masked]

Date: Sun, 20 Apr 2008 11:37:06 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: MIME loops: Extracting attachment to disk and replacing it with an URL
Cc: Alexey Melnikov <[email-masked]>
Sender: [email-masked]

Alexey Melnikov writes:
> It occurred to me that Sieve "replace" from=20
> draft-ietf-sieve-mime-loop-04.txt can almost do that. The only thing=20
> missing is constructing an URL, which will have an =20
> implementation/deployment specific format. One could user Sieve=20
> variables to construct text in the replace action, but only if the=20

Could you elaborate?

> So, do people think that a variant of the replace action is=20

:url doesn't make me feel very good. I'd have many problems getting that =
right.

Arnt

Date: Sun, 20 Apr 2008 11:32:27 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Comments on draft-ietf-sieve-notify-mailto-07.txt
Cc: Alexey Melnikov <[email-masked]>, Barry Leiba <[email-masked]>, Kjetil Torgrim Homme <[email-masked]>
Sender: [email-masked]

Kjetil Torgrim Homme writes:
> yes, but even if the Right Thing is to use redirect, it's quite likely=20
> that a non-trivial amount of people will use notify instead.

There is always the option of sprinking magic DWIM powder over notify-mai=
lto...

     If the message being notified about has an Auto-Submitted
     field, the sieve SHOULD execute a redirect action instead of
     the notify action.

People who write good user interfaces are used to doing such things, but=20
I'm not so sure it's a good idea in a specification like this.

Arnt

Subject: Re: Comments on draft-ietf-sieve-notify-mailto-07.txt
From: Kjetil Torgrim Homme <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: Barry Leiba <[email-masked]>, [email-masked]
Date: Sun, 20 Apr 2008 02:03:43 +0200
Sender: [email-masked]

On Fri, 2008-04-18 at 22:49 +0100, Alexey Melnikov wrote:
> Barry Leiba wrote:
> > 2. Do we have a decision about copying Received lines?  I think we've 
> > reversed ourselves, and no longer want to copy them from the original 
> > message.  Does that mean:
> > a. ...the spec should be changed from MAY copy to SHOULD NOT copy or 
> > MUST NOT copy?  If so, which?
> > b. ...the spec can remain as it is, with MAY (not SHOULD nor MUST)?

Mark's example of wanting to receive notification about automatically
generated alarms makes me wonder if we shouldn't use Received as the
loop prevention mechanism after all.  it's definitely the safest method
of prevention.  the risk is that users will run into hop count limits,
but I think most messages should be well clear of that.

> > 4. We currently say MUST NOT notify if an Auto-Submitted header field 
> > exists (apart from "no").  We had an inconclusive thread going with a 
> > suggestion to change that.  What's the consensus?  If we're to change 
> > it, what should we change it to, given that it's critical to our 
> > loop-prevention story?
> 
> I am weakly in favor of keeping the current logic. I find your argument 
> about using redirect in this case to be convincing.

yes, but even if the Right Thing is to use redirect, it's quite likely
that a non-trivial amount of people will use notify instead.

>    Notification message:
> 
>       Received: from mail.example.com by mail.example.org
>         for <[email-masked]>; Wed, 7 Dec 2005 05:08:02 -0500
>       Received: from hobbies.example.com by mail.example.com
>         for <[email-masked]>; Wed, 7 Dec 2005 02:00:26 -0800
>       Date: Wed, 7 Dec 2005 05:08:55 -0500
>       Message-ID: <[email-masked]>
>       Auto-Submitted: sieve-notify; owner-email="[email-masked]"
>       From: [email-masked]
>       To: [email-masked]
>       To: [email-masked]
>       Subject: From Knitting list: A new sweater

note, multiple To-headers is not allowed by 2822.

-- 
Kjetil T.

From: "Mark E. Mallett" <[email-masked]>
Date: Sat, 19 Apr 2008 14:43:08 -0400
To: [email-masked]
Subject: Re: editheader interaction with mailto notifications
Sender: [email-masked]

On Fri, Apr 18, 2008 at 04:33:29PM -0400, Barry Leiba wrote:
> Ned Freed said the following:
> >Very good point. We have existing users that depend on cascading 
> >notifications,
> >so the way I had planned to implement this is to count auto-submitted 
> >fields
> >and compare against a settable threshhold. The default for the threshhold 
> >will
> >be 1 but operators will be able to set it higher if they choose. 
> 
> There's a problem with that.  RFC 3834 says this, at the end of section 5.1:
>    The maximum number of Auto-Submitted fields that may appear in a
>    message header is 1.

Ouch.  So, Auto-Submitted really isn't a good field to use for loop
control.  If a way to limit the number of cascades is needed (ignoring
for the moment the objection to cascading at all), perhaps some other
trace field could be added.  It might be tempting to add another parameter
to the Auto-Submitted field, but you can't count on those being retained
or maintained.

> We could update that here, but there's no reason to think that there 
> isn't already code out there that strips extra Auto-Submitted headers, 
> and there's every reason to think that setting the threshold > 1 would 
> expose one to problems.

right

> I think it's a Bad Idea to send notifications about Auto-Submitted 
> messages.  Redirect can do it, and redirect ought to be sticking 
> Resent-* headers in.  Those headers are already defined in a way that 
> lets one count them.

I still disagree about that, if only for the meta-examples I gave before
about cascading notifications.  But that's not all.  If, for example, my
monitoring service sends me a message that the heat in my office is
above a certain threshold, this might be Auto-Submitted, yet I would
want to be able to get a notification of it, using the appropriate
language element to do so.  I imagine other examples could flow easily.

I think you have to be careful with prohibitions, and I believe that
this one would practically guarantee that non-conforming implementations
will arise.

mm

From: "Mark E. Mallett" <[email-masked]>
Date: Sat, 19 Apr 2008 14:18:17 -0400
To: [email-masked]
Subject: Re: [Fwd: Re: [secdir] secdir review of draft-ietf-sieve-notify-mailto-07.txt]
Sender: [email-masked]

[hmm, missed this until now]

On Sun, Apr 13, 2008 at 03:54:31PM +0100, Alexey Melnikov wrote:
> Mark E. Mallett wrote:
> 
> >I didn't [intend to] suggest getting rid of the envelope-to field from
> >the list of choices, but only to add an address associated with the
> >Sieve script to that list.  I think the owner's address is at least as
> >good a choice for a fixed address as a system-wide one.  It may be
> >more readable to express it as a list, e.g.:
> >
> >  If ":from" is not specified or is not valid, the envelope 
> >  sender of the notification message SHOULD be selected from
> >  one of the following, at the discretion of the implementation:
> >    - the envelope "to" field from the triggering message, as used
> >      by Sieve;
> >    - the address of the owner of the Sieve script;
> > 
> >
> But "the envelope "to"..." is "an address of the owner".

But not necessarily *the* address of the owner, i.e., not a fixed
address.

Note also that this mention of the "envelope 'to'" should probably be
qualified as "final envelope to" (the word "final") as has been done
elsewhere.

> If multiple email aliases go to the same mailbox, I think it would be 
> better to use the envelope "to", so that a recipient of mailto 
> notifications can distinguish between different aliases.

I see that, too; and I wouldn't want an implementation to be prevented
from doing that.  But see below.

> >    - an email address associated with the notification system.

I'm actually not really happy with that wording "the address of the
owner of the Sieve script" either.  What I am really aiming for (as
quoted above, even) is to allow an implementation to optionally be
configured with an email address associated with notification messages
for any individual mailbox, and that it could choose to use that as a
default return address if present.

I agree that the envelope-to is the best choice if the application
hasn't been configured to use a fixed address.  But I also think that
having the only choice for a fixed address be a system-wide one isn't
fine-grained enough.  So maybe instead of "the address of the owner
of the Sieve script", more like:

  - an email address associated with notification messages sent on
    behalf of the email-address receiving the message;

and it's up to the implementation how that association is made, or
whether it's made at all.  One could actually interpret that to cover a
system-wide address, as well, maybe with some slight fiddling, so that
the other choice (the "email address associated with the notification
system") could be dropped.

This seems awfully trivial but I'm having a hard time being concise
about it, sorry.

mm

Date: Fri, 18 Apr 2008 22:49:22 +0100
From: Alexey Melnikov <[email-masked]>
To: Barry Leiba <[email-masked]>
CC: [email-masked]
Subject: Re: Comments on draft-ietf-sieve-notify-mailto-07.txt
Sender: [email-masked]

Barry Leiba wrote:

> OK, I'm wrapping things up with mailto-07, preparing mailto-08.

Speaking as an individual contributor:

> Here are the issues that I have to resolve:
>
> 1. There was a problem with the IANA Considerations subsection 2, 
> which I've fixed.  No WG action needed here.

Good. But can you tell the WG what has changed?

> 2. Do we have a decision about copying Received lines?  I think we've 
> reversed ourselves, and no longer want to copy them from the original 
> message.  Does that mean:
> a. ...the spec should be changed from MAY copy to SHOULD NOT copy or 
> MUST NOT copy?  If so, which?
> b. ...the spec can remain as it is, with MAY (not SHOULD nor MUST)?

I don't care if the specification does a) or b), however it needs to be 
updated in other places to make sure it doesn't mislead the reader that 
copying Received headers is the loop prevention mechanism.
In the case a). the example in section 3 must also be updated not to 
show Received headers copied from the original message.

> c. ...the spec should say that you can do anything you please?
>
> 3. What did we decide for the value on the Auto-Submitted header?  I 
> still have it as "Sieve-Notify".  Do we want to change it to 
> "Auto-Notification"?  Something else?

I prefer Auto-Notification, but I don't have a strong opinion.

> 4. We currently say MUST NOT notify if an Auto-Submitted header field 
> exists (apart from "no").  We had an inconclusive thread going with a 
> suggestion to change that.  What's the consensus?  If we're to change 
> it, what should we change it to, given that it's critical to our 
> loop-prevention story?

I am weakly in favor of keeping the current logic. I find your argument 
about using redirect in this case to be convincing.

> 5. It seems that we're OK with most of the header handling being 
> SHOULD, but we still have to nail down the Subject header.  Note that 
> the text that's there, which says MUST for the first bit and SHOULD 
> for the rest allows implementations to alter text from user-generated 
> subjects, in case they might be problematic.  That's intentional, and 
> if we change to MUST there, we have to make exceptions.  Also, the 
> part that says it SHOULD fall back to what's in the triggering message 
> is also intentional: there are applications where the message subject 
> is considered secret, and the implementation will know that it should 
> never include it.  We don't want a MUST there.

You lost me here. The text in question is:

   o  The "Subject:" field of the notification message MUST contain the
      value defined by the :message notify tag, as described in
      [Notify].  If there is no :message tag and there is a "subject"
      header on the URI, then that value SHOULD be used.  If that is
      also absent, the subject SHOULD be retained from the triggering
      message.  Note that Sieve [Variables] can be used to advantage
      here, as shown in the example in Section 3.

According to what you are saying, the first MUST must be changed to 
SHOULD, because it is "user-generated subject". I don't care that much 
about SHOULD versa MUST, but I do care that the first and the second 
SHOULD/MUST are the same, as, IMHO, they are just 2 different forms of 
the same thing.

> 6. Alexey gummed things up (SLAP!) by bringing up the References 
> header.  I don't see a decision on that, so I'll wait for one.

Ok, I can try to think about some suggested text, but don't wait for it 
before posting -08.

> 7. Alexey thinks we should have an example that shows more complex use 
> of URI headers, in particular one that combines a mailto address with 
> a to= URI header.  I see no reason to do that.  Does anyone else think 
> it's useful to add such an example?  If so, that person should write 
> one and post it here.

Here (replace 2/3rds of the existing example in section 3):

    Sieve script (run on behalf of [email-masked]):

      require ["notify", "variables"];

      if header :contains "list-id" "knitting.example.com" {
        if header :matches "Subject" "[*] *" {
          notify :message "From ${1} list: ${2}"
                 :importance "3"
                 "mailto:[email-masked]?to=[email-masked]";
        }
      }

   Notification message:

      Received: from mail.example.com by mail.example.org
        for <[email-masked]>; Wed, 7 Dec 2005 05:08:02 -0500
      Received: from hobbies.example.com by mail.example.com
        for <[email-masked]>; Wed, 7 Dec 2005 02:00:26 -0800
      Date: Wed, 7 Dec 2005 05:08:55 -0500
      Message-ID: <[email-masked]>
      Auto-Submitted: sieve-notify; owner-email="[email-masked]"
      From: [email-masked]
      To: [email-masked]
      To: [email-masked]
      Subject: From Knitting list: A new sweater

Which reminded me of another question: should we describe how to handle "?cc=..."?

> I don't have to wait for ALL of these to be resolved before I post 
> -08, but I'd like to get at least a few of them resolved first.  So I 
> await the WG's swift action.......

Date: Fri, 18 Apr 2008 17:04:26 -0400
From: Barry Leiba <[email-masked]>
To: [email-masked]
Subject: Re: Comments on draft-ietf-sieve-notify-mailto-07.txt
Sender: [email-masked]

OK, I'm wrapping things up with mailto-07, preparing mailto-08.

Here are the issues that I have to resolve:

1. There was a problem with the IANA Considerations subsection 2, which 
I've fixed.  No WG action needed here.

2. Do we have a decision about copying Received lines?  I think we've 
reversed ourselves, and no longer want to copy them from the original 
message.  Does that mean:
a. ...the spec should be changed from MAY copy to SHOULD NOT copy or 
MUST NOT copy?  If so, which?
b. ...the spec can remain as it is, with MAY (not SHOULD nor MUST)?
c. ...the spec should say that you can do anything you please?

3. What did we decide for the value on the Auto-Submitted header?  I 
still have it as "Sieve-Notify".  Do we want to change it to 
"Auto-Notification"?  Something else?

4. We currently say MUST NOT notify if an Auto-Submitted header field 
exists (apart from "no").  We had an inconclusive thread going with a 
suggestion to change that.  What's the consensus?  If we're to change 
it, what should we change it to, given that it's critical to our 
loop-prevention story?

5. It seems that we're OK with most of the header handling being SHOULD, 
but we still have to nail down the Subject header.  Note that the text 
that's there, which says MUST for the first bit and SHOULD for the rest 
allows implementations to alter text from user-generated subjects, in 
case they might be problematic.  That's intentional, and if we change to 
MUST there, we have to make exceptions.  Also, the part that says it 
SHOULD fall back to what's in the triggering message is also 
intentional: there are applications where the message subject is 
considered secret, and the implementation will know that it should never 
include it.  We don't want a MUST there.

6. Alexey gummed things up (SLAP!) by bringing up the References header. 
  I don't see a decision on that, so I'll wait for one.

7. Alexey thinks we should have an example that shows more complex use 
of URI headers, in particular one that combines a mailto address with a 
to= URI header.  I see no reason to do that.  Does anyone else think 
it's useful to add such an example?  If so, that person should write one 
and post it here.

I don't have to wait for ALL of these to be resolved before I post -08, 
but I'd like to get at least a few of them resolved first.  So I await 
the WG's swift action.......

Barry

Date: Fri, 18 Apr 2008 16:33:29 -0400
From: Barry Leiba <[email-masked]>
To: Ned Freed <[email-masked]>
CC: Mark E Mallett <[email-masked]>, [email-masked]
Subject: Re: editheader interaction with mailto notifications
Sender: [email-masked]

Ned Freed said the following:
> Very good point. We have existing users that depend on cascading notifications,
> so the way I had planned to implement this is to count auto-submitted fields
> and compare against a settable threshhold. The default for the threshhold will
> be 1 but operators will be able to set it higher if they choose. 

There's a problem with that.  RFC 3834 says this, at the end of section 5.1:
    The maximum number of Auto-Submitted fields that may appear in a
    message header is 1.

We could update that here, but there's no reason to think that there 
isn't already code out there that strips extra Auto-Submitted headers, 
and there's every reason to think that setting the threshold > 1 would 
expose one to problems.

I think it's a Bad Idea to send notifications about Auto-Submitted 
messages.  Redirect can do it, and redirect ought to be sticking 
Resent-* headers in.  Those headers are already defined in a way that 
lets one count them.

Barry

Date: Fri, 18 Apr 2008 15:04:32 +0100
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: MIME loops: Extracting attachment to disk and replacing it with an URL
Sender: [email-masked]

Date: Sun, 13 Apr 2008 15:54:31 +0100
From: Alexey Melnikov <[email-masked]>
To: "Mark E. Mallett" <[email-masked]>
CC: [email-masked]
Subject: Re: [Fwd: Re: [secdir] secdir review of draft-ietf-sieve-notify-mailto-07.txt]
Sender: [email-masked]

Mark E. Mallett wrote:

>I didn't [intend to] suggest getting rid of the envelope-to field from
>the list of choices, but only to add an address associated with the
>Sieve script to that list.  I think the owner's address is at least as
>good a choice for a fixed address as a system-wide one.  It may be
>more readable to express it as a list, e.g.:
>
>   If ":from" is not specified or is not valid, the envelope 
>   sender of the notification message SHOULD be selected from
>   one of the following, at the discretion of the implementation:
>     - the envelope "to" field from the triggering message, as used
>       by Sieve;
>     - the address of the owner of the Sieve script;
>  
>
But "the envelope "to"..." is "an address of the owner".
If multiple email aliases go to the same mailbox, I think it would be 
better to use the envelope "to", so that a recipient of mailto 
notifications can distinguish between different aliases.

>     - an email address associated with the notification system.
>
>At any rate, I was attempting to add one thing to the list of choices,
>not subtract from it.
>  
>

From: "Mark E. Mallett" <[email-masked]>
Date: Sat, 12 Apr 2008 14:05:58 -0400
To: [email-masked]
Subject: Re: [Fwd: Re: [secdir] secdir review of draft-ietf-sieve-notify-mailto-07.txt]
Sender: [email-masked]

On Fri, Apr 11, 2008 at 12:22:41PM +0200, Michael Haardt wrote:
> 
> Let me try to get rid of the quoted discussion.  We ended up with
> this so far:
> 
>   If ":from" is not specified or is not valid, the envelope 
>   sender of the notification message SHOULD be set either to the 
>   envelope "to" field from the triggering message, as used by 
>   Sieve, or to an email address associated with the notification system,
>   at the discretion of the implementation.
> 
> Now you suggest, after we got rid of the fixed address of the notification
> system, we should get rid of the fixed envelope "to" field as well and
> replace it with "the address of the owner of the Sieve script", which
> is what vacation does.  The version would be:
> 
>   If ":from" is not specified or is not valid, the envelope 
>   sender of the notification message SHOULD be set either to the 
>   the address of the owner of the Sieve script,
>   or to an email address associated with the notification system,
>   at the discretion of the implementation.
> 
> Correct so far?

I didn't [intend to] suggest getting rid of the envelope-to field from
the list of choices, but only to add an address associated with the
Sieve script to that list.  I think the owner's address is at least as
good a choice for a fixed address as a system-wide one.  It may be
more readable to express it as a list, e.g.:

   If ":from" is not specified or is not valid, the envelope 
   sender of the notification message SHOULD be selected from
   one of the following, at the discretion of the implementation:
     - the envelope "to" field from the triggering message, as used
       by Sieve;
     - the address of the owner of the Sieve script;
     - an email address associated with the notification system.

At any rate, I was attempting to add one thing to the list of choices,
not subtract from it.

mm

Date: Fri, 11 Apr 2008 12:22:41 +0200
To: [email-masked]
Subject: Re: [Fwd: Re: [secdir] secdir review of draft-ietf-sieve-notify-mailto-07.txt]
From: Michael Haardt <[email-masked]>
Sender: [email-masked]

Let me try to get rid of the quoted discussion.  We ended up with
this so far:

  If ":from" is not specified or is not valid, the envelope 
  sender of the notification message SHOULD be set either to the 
  envelope "to" field from the triggering message, as used by 
  Sieve, or to an email address associated with the notification system,
  at the discretion of the implementation.

Now you suggest, after we got rid of the fixed address of the notification
system, we should get rid of the fixed envelope "to" field as well and
replace it with "the address of the owner of the Sieve script", which
is what vacation does.  The version would be:

  If ":from" is not specified or is not valid, the envelope 
  sender of the notification message SHOULD be set either to the 
  the address of the owner of the Sieve script,
  or to an email address associated with the notification system,
  at the discretion of the implementation.

Correct so far?

Sounds good to me. :)

Michael

Cc: [email-masked]
Date: Thu, 10 Apr 2008 07:56:13 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: editheader interaction with mailto notifications
To: Mark E Mallett <[email-masked]>
Sender: [email-masked]

> On Fri, Apr 04, 2008 at 09:32:53PM +0200, Arnt Gulbrandsen wrote:
> >
> > Alexey Melnikov writes:
> > >I am wondering if editheader should also prohibit deletion of
> > >Auto-Submitted, as it is used for loop prevention in mailto notify
> > >document.
> > >
> > >Thoughts?
> >
> > The reason is IMO insufficient, but the idea is good.
> >

> I suppose this is as good a place as any to bring this up..  I'm a
> bit wary of this:

>    > Implementations MUST NOT trigger notifications for messages
>    > containing "Auto-Submitted:" header fields with any value other than
>    > "No".

> and some other similar text.  The stated reason is for loop prevention,
> but as written, what it seems to be preventing is cascading
> notifications, not loops.  I can easily envision somebody wanting to
> trigger a notification based on another notification, e.g.:

>    A sends to B
>    B sends notify to C
>    C sees the notify and wants to notify D as well.

> where any of the above could be role accounts or lists.

Very good point. We have existing users that depend on cascading notifications,
so the way I had planned to implement this is to count auto-submitted fields
and compare against a settable threshhold. The default for the threshhold will
be 1 but operators will be able to set it higher if they choose. 

Depending on what the specifications say the documentation will include
apprpropriate warnings about how this is a standards violation and so on.

> We have no such prohibitions on redirects, where cascading them is (good
> or bad) quite common.  I wouldn't want to see them on mailto notify
> either.  Which doesn't negate the fact that I think that one would still
> want to take extreme care when generating a notify based on mail with an
> Auto-Submitted field in it -- but I would leave that as a caution to a
> script writer, not a limitation imposed on the underlying
> implementation.

I think that leaves things a little too open. I would suggest that we instead
require checking for Auto-submitted fields but leave open the threshhold at
which notifies are blocked - the same sort of language we have elsewhere
regarding Received: fields.

> The interesting thing is that this draft specifies some new
> Auto-Submitted parameters which *can* be used for loop control.  I think
> it would be much more useful to say that if the message contains an
> Auto-Submitted header field with any value other than "no" *and* with
> either an "owner-email" or "owner-token" field that is associated with
> the currently running delivery, then the notification should not be
> done.  I sort of wonder if that was what was in mind when these
> parameters were added, since they seem perfectly suited to it.

As I recall this was intended for tracing purposes. However, an alternative
would be to require the use of these paramters and then require that
they be checked.

I worry, however, that not all scripting environments will have the ability to
generate appropriate values for these parameters.

				Ned

Date: Wed, 9 Apr 2008 15:04:53 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: ManageSieve: allowed characters in script names
Cc: Alexey Melnikov <[email-masked]>, Jeffrey Hutzelman <[email-masked]>, Kjetil Torgrim Homme <[email-masked]>
Sender: [email-masked]

Kjetil Torgrim Homme writes:
> On Tue, 2008-04-08 at 11:17 -0400, Jeffrey Hutzelman wrote:
>>  Alexey Melnikov <[email-masked]> wrote:
>>  > Is this reasonable? I think we should at least prohibit other ASCII
>>  > control characters.
>
> I think it is reasonable to require the character to be printable.=20
> e.g., we don't want Unicode BOM in there, either.

Agree.

> I'm in favour of setting aside one character for hierarchy purposes=20
> though, e.g. "/", even if it has no meaning today.

If / is reserved, then I suggest that U+2044 =E2=81=84 and U+2215 =E2=88=95=
 should be=20
forbidden. Otherwise one clever client will substitute =E2=81=84 for / =
when=20
uploading a script, and wen the types / into another client, that other=20
client can't download the script.

Yes, I know visual similarity is a big issue. Dealing with all of it is=20
not worth it. Dealing with just this little bit is, IMO.

Arnt

Subject: Re: ManageSieve: allowed characters in script names
From: Kjetil Torgrim Homme <[email-masked]>
To: Jeffrey Hutzelman <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, MTA filtering mailing list <[email-masked]>
Date: Wed, 09 Apr 2008 14:28:35 +0200
Sender: [email-masked]

On Tue, 2008-04-08 at 11:17 -0400, Jeffrey Hutzelman wrote:
> Alexey Melnikov <[email-masked]> wrote:
> > Is this reasonable? I think we should at least prohibit other ASCII
> > control characters.

I think it is reasonable to require the character to be printable.
e.g., we don't want Unicode BOM in there, either.

> > Isode's implementation is even more restrictive, as it disallows =C2=AC=
, :,
> > /, etc. Should they be allowed?
>=20
> There are certainly some classes of characters, such as letters and digit=
s,=20
> that all implementations should accept.  But there also should be some=20
> flexibility; for example, some implementations may find it useful to=20
> disallow some subset of [][/\\:;,] or other characters, depending on the=20
> underlying OS.

please let us not go down that route, the list of potentially
problematic characters is endless.  an implementation can easily use,
say, a URL-style encoding if it uses a filesystem as its store.

I'm in favour of setting aside one character for hierarchy purposes
though, e.g. "/", even if it has no meaning today.

--=20
Kjetil T.

Date: Tue, 08 Apr 2008 11:17:30 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Alexey Melnikov <[email-masked]>, MTA filtering mailing list <[email-masked]>
cc: [email-masked]
Subject: Re: ManageSieve: allowed characters in script names
Sender: [email-masked]

--On Tuesday, April 08, 2008 04:00:41 PM +0100 Alexey Melnikov=20
<[email-masked]> wrote:

>
> draft-martin-managesieve-08.txt [currently expired], section 1.7 says:
>
>     Sieve script names may contain any valid UTF-8 characters, except
>     for NUL, CR or LF. Names MUST be at least one octet long. Zero
>     octets script name has special meaning (see SETACTIVE command
>     section). Servers MUST allow names of up to 128 Unicode characters
>     in length, and MAY allow longer names.
>
> Is this reasonable? I think we should at least prohibit other ASCII
> control characters.

There are probably a number of unicode characters we should prohibit.
Take a look at the tables in the stringprep document, but bear in mind that =

current thinking seems to be that such prohibitions should be based on=20
unicode character properties rather than on explicit lists.

It may be appropriate here to apply stringprep to script names, but it may=20
also not be necessary.

> Isode's implementation is even more restrictive, as it disallows =C2=AC, =
:,
> /, etc. Should they be allowed?

There are certainly some classes of characters, such as letters and digits, =

that all implementations should accept.  But there also should be some=20
flexibility; for example, some implementations may find it useful to=20
disallow some subset of [][/\\:;,] or other characters, depending on the=20
underlying OS.

-- Jeff

Date: Tue, 08 Apr 2008 16:00:41 +0100
From: Alexey Melnikov <[email-masked]>
To: MTA filtering mailing list <[email-masked]>
Subject: ManageSieve: allowed characters in script names
Sender: [email-masked]

draft-martin-managesieve-08.txt [currently expired], section 1.7 says:

    Sieve script names may contain any valid UTF-8 characters, except
    for NUL, CR or LF. Names MUST be at least one octet long. Zero
    octets script name has special meaning (see SETACTIVE command
    section). Servers MUST allow names of up to 128 Unicode characters
    in length, and MAY allow longer names.

Is this reasonable? I think we should at least prohibit other ASCII=20
control characters.

Isode's implementation is even more restrictive, as it disallows =AC, :,=20
/, etc. Should they be allowed?

Date: Tue, 08 Apr 2008 09:44:51 +0100
From: Alexey Melnikov <[email-masked]>
To: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= <[email-masked]>
CC: IETF Sieve WG <[email-masked]>
Subject: Re: refuse-reject SMTP multi-lines replies
Sender: [email-masked]

=D0=94=D0=B8=D0=BB=D1=8F=D0=BD =D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=
=B2 wrote:

> Hi all,

Hi =D0=94=D0=B8=D0=BB=D1=8F=D0=BD,

> Section 2.1.2 of draft-ietf-sieve-refuse-reject-06 speaks about how to=20
> not-accpept a message (Action ereject, Rejecting a message at the=20
> SMTP/LMTP protocol level).
>
> It might happen, that the ereject's parameter is longer than 512=20
> characters, or it can be multilined (e.g
>   ereject "First line
>   second line";
> ). The line terminators within the script are not necessary CR and LF,=20
> it can be only CR or only LF. (at least cyrus' timsieved allows only LF).

RFC 5228 only allows for CRLF as end-of-line markers, so this document=20
shouldn't care about bare CRs or bare LFs used in scripts.

> Do you think it is appropriate to specify in the draft, when it comes=20
> to SMTP, one of:
>
>     - If the ejerect's parameter consists of several lines, that lines=20
> are merged into one single line. This line is split in portions of=20
> about 500 characters (the number comes from RFC 2821, Section 4.5.3.1,=20
> "reply line"; subtracting from 512 the length of "250"/"550" code and=20
> the lengtt of enhanced status codes), when possible no word is=20
> hyphenated. Each portion of the so created string-list is returned on=20
> a separate smtp line in a multi-line SMPT reply;
>
>     - (If the ereject's parameter consists of several lines, the line=20
> separators are replaced with CRLF.?)

As per RFC 5228, this statement is not needed.

> The SMTP makes multi-line reply, giving every line of the=20
> reason-parameter on as a separate line in the SMTP dialog. (this=20
> leaves unhandled the case, when a single line is longer than 512);
>
>     - If the ereject's parameter is longer than 500 characters, it is=20
> truncated to 500 characters.

Personally, I don't like the 3rd choice. I would prefer to do a hybrid=20
of your proposal 1 and proposal 2: try to preserve existing CRLFs in the=20
text, but insert additional ones, if any single line is longer than 500=20
characters.

>     Of course with the usual sense of "Shall/Must/Might/" etc. My=20
> question is more if the draft shall deal with very-long-multi-lined=20
> ereject-parameters, than what to do exactly.

Date: Mon, 7 Apr 2008 12:10:56 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: editheader interaction with mailto notifications
Cc: "Mark E. Mallett" <[email-masked]>
Sender: [email-masked]

Mark E. Mallett writes:
> I suppose this is as good a place as any to bring this up.. I'm a bit 
> wary of this:
>
>    > Implementations MUST NOT trigger notifications for messages
>    > containing "Auto-Submitted:" header fields with any value other than
>    > "No".
>
> and some other similar text. The stated reason is for loop prevention, 
> but as written, what it seems to be preventing is cascading 
> notifications, not loops. I can easily envision somebody wanting to 
> trigger a notification based on another notification, e.g.:
>
>    A sends to B
>    B sends notify to C
>    C sees the notify and wants to notify D as well.
>
> where any of the above could be role accounts or lists.

(C can do that using redirect as well as notify.)

I don't like notifying about auto-submitted mail. Redirecting is better, 
that gives B's MTA a chance to detect the loop should one occur.

> We have no such prohibitions on redirects, where cascading them is 
> (good or bad) quite common. I wouldn't want to see them on mailto 
> notify either. Which doesn't negate the fact that I think that one 
> would still want to take extreme care when generating a notify based 
> on mail with an Auto-Submitted field in it -- but I would leave that 
> as a caution to a script writer, not a limitation imposed on the 
> underlying implementation.

Not one script writer, but two. B and C. If they are the ones who have 
to be careful, they have to coordinate and be careful together.

I'd prefer to place more emphasis on loop prevention in the standard, 
and demand less care by the n pairs of script writers.

Arnt

From: "Mark E. Mallett" <[email-masked]>
Date: Sun, 6 Apr 2008 16:09:58 -0400
To: [email-masked]
Subject: Re: editheader interaction with mailto notifications
Sender: [email-masked]

On Fri, Apr 04, 2008 at 09:32:53PM +0200, Arnt Gulbrandsen wrote:
> 
> Alexey Melnikov writes:
> >I am wondering if editheader should also prohibit deletion of 
> >Auto-Submitted, as it is used for loop prevention in mailto notify 
> >document.
> >
> >Thoughts?
> 
> The reason is IMO insufficient, but the idea is good.
> 

I suppose this is as good a place as any to bring this up..  I'm a
bit wary of this:

   > Implementations MUST NOT trigger notifications for messages
   > containing "Auto-Submitted:" header fields with any value other than
   > "No".

and some other similar text.  The stated reason is for loop prevention,
but as written, what it seems to be preventing is cascading
notifications, not loops.  I can easily envision somebody wanting to
trigger a notification based on another notification, e.g.:

   A sends to B
   B sends notify to C
   C sees the notify and wants to notify D as well.

where any of the above could be role accounts or lists.

We have no such prohibitions on redirects, where cascading them is (good
or bad) quite common.  I wouldn't want to see them on mailto notify
either.  Which doesn't negate the fact that I think that one would still
want to take extreme care when generating a notify based on mail with an
Auto-Submitted field in it -- but I would leave that as a caution to a
script writer, not a limitation imposed on the underlying
implementation.

The interesting thing is that this draft specifies some new
Auto-Submitted parameters which *can* be used for loop control.  I think
it would be much more useful to say that if the message contains an
Auto-Submitted header field with any value other than "no" *and* with
either an "owner-email" or "owner-token" field that is associated with
the currently running delivery, then the notification should not be
done.  I sort of wonder if that was what was in mind when these
parameters were added, since they seem perfectly suited to it.

(This should not prohibit other loop control mechanisms such as
the common "Delivered-To" field.)

It's easily possible that I've misinterpreted something..

Yours,
mm

From: "Mark E. Mallett" <[email-masked]>
Date: Sun, 6 Apr 2008 15:51:46 -0400
To: [email-masked]
Subject: Re: [Fwd: Re: [secdir] secdir review of draft-ietf-sieve-notify-mailto-07.txt]
Sender: [email-masked]

On Wed, Apr 02, 2008 at 01:05:17PM +0100, Alexey Melnikov wrote:
> 
> Michael Haardt wrote:
> 
> >>>>>    If ":from" is not specified or is not valid, the envelope 
> >>>>>sender      of the notification message SHOULD be set either to the 
> >>>>>    envelope "to" field from the triggering message, as used by 
> >>>>>    Sieve, or to a fixed email address (so it "comes from the      
> >>>>>notification system"), at the discretion of the implementation.
> >>>>>
> >>>>>already list all possible alternatives, so I don't think it is a 
> >>>>>SHOULD either.
> >>>>>         
> >>>>>
> >>>Those aren't all possible alternatives, so although I don't mind MUST 
> >>>I rather like keeping SHOULD. (One other alternative is a system 
> >>>address with a single-use subaddress.)
> >>>     
> >>>
> >>Ok, you and Barry have convinced me that this SHOULD is fine.
> >>Also, how about deleting the word "fixed" above?
> >>   
> >>
> >"Fixed" does indeed not hit the point, but do you have a better
> >suggestion?
> >
> >The idea was to allow the system to used a fixed address, or a fixed
> >addressing scheme, no matter if the variable part is a RFC subadressing
> >detail or some other kind of subadressing, that can be recognised as such,
> >telling the mail "comes from the notification system".  The quoted part
> >tells exactly what was tried to express.  I would appreciate a better
> >wording, but can't think of any.
> > 
> >
> I think the following would be better:
> 
> or to an email address associated with the notification system
> 
> This avoids the argument about whether there is a single addresse, whether 
> it must be completely static, etc.

Sorry to quote so much, but it's all relevant, I think.

Even though it adds another case, I would also consider the example
set by the vacation extension, which says:

     Unless explicitly overridden with a :from parameter, the From field
     SHOULD be set to the address of the owner of the Sieve script.

To me, this is preferable to defaulting to a system-wide notification
address, so I would want to add "the address of the owner of the sieve
script" into the mix as another possibility for a default.  I suppose
that the current wording could be interpreted to mean a fixed address
associated with the user, since it says only "a fixed email address" but
the parenthetical comment '(so it "comes from the notification system")'
almost certainly refines it to mean a fixed system-wide address.

(This might be seen as ironic, since as you may recall that I didn't
like that exact wording in 'vacation', but I did agree with the spirit.
And now the precedent is there so...)

mm

X-Mail-Sent-By-AEGEE.org-Account: didopalauzov
Date: Sun, 06 Apr 2008 21:19:27 +0200
From: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= <[email-masked]>
To: IETF Sieve WG <[email-masked]>
Subject: refuse-reject SMTP multi-lines replies
Sender: [email-masked]

Hi all,

Section 2.1.2 of draft-ietf-sieve-refuse-reject-06 speaks about how to 
not-accpept a message (Action ereject, Rejecting a message at the 
SMTP/LMTP protocol level).

It might happen, that the ereject's parameter is longer than 512 
characters, or it can be multilined (e.g
   ereject "First line
   second line";
). The line terminators within the script are not necessary CR and LF, 
it can be only CR or only LF. (at least cyrus' timsieved allows only LF).

Do you think it is appropriate to specify in the draft, when it comes to 
SMTP, one of:

	- If the ejerect's parameter consists of several lines, that lines are 
merged into one single line. This line is split in portions of about 500 
characters (the number comes from RFC 2821, Section 4.5.3.1, "reply 
line"; subtracting from 512 the length of "250"/"550" code and the 
lengtt of enhanced status codes), when possible no word is hyphenated. 
Each portion of the so created string-list is returned on a separate 
smtp line in a multi-line SMPT reply;

	- (If the ereject's parameter consists of several lines, the line 
separators are replaced with CRLF.?) The SMTP makes multi-line reply, 
giving every line of the reason-parameter on as a separate line in the 
SMTP dialog. (this leaves unhandled the case, when a single line is 
longer than 512);

	- If the ereject's parameter is longer than 500 characters, it is 
truncated to 500 characters.

	Of course with the usual sense of "Shall/Must/Might/" etc. My question 
is more if the draft shall deal with very-long-multi-lined 
ereject-parameters, than what to do exactly.

	Със здраве,
		Дилян

Date: Sat, 5 Apr 2008 21:45:14 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: editheader interaction with mailto notifications
Cc: Alexey Melnikov <[email-masked]>
Sender: [email-masked]

Alexey Melnikov writes:
> Arnt, can you elaborate on why you think the reason is not sufficient?

Sorry. I should have done so in the first place. If I had tried to 
formulate my intuitive thoughts I would have ended up with a something 
like: "Editheader SHOULD NOT allow removing Auto-Submitted, because 
it's known to be used for loop prevention. Disturbing someone's loop 
prevention logic is both rude and harmful."

Editheader shouldn't be courteous to mailto-notify because both are 
sieve systems. It should be courteous to everyone because mail loops 
are $#@!$#$!@ painful.

Arnt

Date: Sat, 05 Apr 2008 11:11:07 +0100
From: Alexey Melnikov <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
CC: [email-masked]
Subject: Re: editheader interaction with mailto notifications
Sender: [email-masked]

Arnt Gulbrandsen wrote:

> Alexey Melnikov writes:
>
>> I am wondering if editheader should also prohibit deletion of 
>> Auto-Submitted, as it is used for loop prevention in mailto notify 
>> document.
>>
>> Thoughts?
>
> The reason is IMO insufficient, but the idea is good.

Arnt, can you elaborate on why you think the reason is not sufficient?

Thanks,
Alexey

Date: Fri, 4 Apr 2008 21:32:53 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: editheader interaction with mailto notifications
Cc: Alexey Melnikov <[email-masked]>
Sender: [email-masked]

Alexey Melnikov writes:
> I am wondering if editheader should also prohibit deletion of 
> Auto-Submitted, as it is used for loop prevention in mailto notify 
> document.
>
> Thoughts?

The reason is IMO insufficient, but the idea is good.

Arnt

Cc: MTA filtering mailing list <[email-masked]>
Date: Fri, 04 Apr 2008 11:46:17 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: editheader interaction with mailto notifications
To: Alexey Melnikov <[email-masked]>
Sender: [email-masked]

> Folks,
> I am wondering if editheader should also prohibit deletion of
> Auto-Submitted, as it is used for loop prevention in mailto notify document.

Seems reasonable to me.

				Ned

Date: Thu, 03 Apr 2008 15:50:49 -0400
From: Jeffrey Hutzelman <[email-masked]>
To: Barry Leiba <[email-masked]>, Alexey Melnikov <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: Comments on draft-ietf-sieve-notify-mailto-07.txt
Sender: [email-masked]

--On Thursday, April 03, 2008 09:16:58 AM -0400 Barry Leiba 
<[email-masked]> wrote:

> Don't pick at that -- it's just an example.  The point is that we can't
> anticipate all the issues that might arise.  We can just say MUST when
> we're defining something that will break interoperability if it's not
> followed, and SHOULD or MAY otherwise.  For most of these fields, there's
> NO GOOD REASON to use MUST.  There just isn't.
>
> So we SHOULDN'T.

Again, this is exactly right.  SHOULD is much stronger than people give it 
credit for, and MUST is properly used very sparingly.  If breaking a 
requirement would cause problems with interoperability, security, 
correctness, uncontrolled congestion on the Internet, etc, then MUST is 
appropriate.  Otherwise, it really is not.

-- Jeff

Date: Thu, 03 Apr 2008 19:45:03 +0100
From: Alexey Melnikov <[email-masked]>
To: MTA filtering mailing list <[email-masked]>
Subject: editheader interaction with mailto notifications
Sender: [email-masked]

Folks,
I am wondering if editheader should also prohibit deletion of  
Auto-Submitted, as it is used for loop prevention in mailto notify document.

Thoughts?

Date: Thu, 03 Apr 2008 18:43:06 +0100
From: Alexey Melnikov <[email-masked]>
To: SIEVE <[email-masked]>
Subject: Re: Charter update
Sender: [email-masked]

Cyrus Daboo wrote:

> (2) Finalize and publish the following SIEVE extensions as proposed 
> standards:
>
>     (a) iHave (draft-freed-sieve-ihave-01.txt)
>     (b) Notary (draft-freed-sieve-notary-01.txt)
>     (c) SIEVE in XML (draft-freed-sieve-in-xml-01.txt)
>     (d) Notify-sip (draft-melnikov-sieve-notify-sip-message-01.txt)
>     (e) ManageSIEVE (draft-martin-managesieve-08.txt)
>     (f) RegEx (draft-ietf-sieve-regex-00.txt)
>     (g) Meta-data (draft-melnikov-sieve-imapext-metadata-03.txt)
>     (h) Include/multi-script (draft-daboo-sieve-include-05.txt)
>     (i) Address data (draft-melnikov-sieve-external-lists-01)

I've just remembered: what has happened to the document describing 
'envelope "auth"'

Date: Thu, 03 Apr 2008 17:22:17 +0100
From: Alexey Melnikov <[email-masked]>
To: Michael Haardt <[email-masked]>
CC: [email-masked]
Subject: Re: Comments on draft-ietf-sieve-notify-mailto-07.txt
Sender: [email-masked]

Michael Haardt wrote:

>>In section 2.7:
>>
>>   o  The "To:" header field and the envelope recipient(s) of the
>>      notification message SHOULD be set to the address(es) specified in
>>      the URI (including any URI headers where the hname is "to").
>>
>>
>>I think there is a problem with this text. Surely the envelope recipient 
>>is specified in the mailto URI itself, not in the to URI header. (Your 
>>example in section 3 confirms that.) For example if mailto URI is 
>>"mailto:[email-masked]?to=[email-masked]", then the 
>>envelope recipient is [email-masked] and not 
>>[email-masked].
>>
>>I think the text is also trying to say that both To: header and envelope 
>>to should be set to the same value.
>>    
>>
>To me, the text is correct.  From draft-duerst-mailto-bis-05, section 2.:
>
>   Also note that it is legal to specify both <to> and an <hfname> whose
>   value is "to".  That is,
>
>   <mailto:[email-masked][email-masked]>
>
>   is equivalent to
>
>   <mailto:?to=[email-masked][email-masked]>
>
>   is equivalent to
>
>   <mailto:[email-masked]?to=[email-masked]>
>
Ok. I should have checked this myself.

I think it would be helpful if you/Barry add a clarifying example to 
demonstrate this.

>The text asks for both header and envelope recipients to be set to
>the recipients specified in the URI, and reminds the reader that
>URIs may contain recipients as URI headers, too.
>  
>
>>   o  The "Subject:" field of the notification message MUST contain the
>>      value defined by the :message notify tag, as described in
>>      [Notify].  If there is no :message tag and there is a "subject"
>>      header on the URI, then that value SHOULD be used.
>>
>>
>>I think this SHOULD should be upgraded to a MUST. Reason: I can see use 
>>cases when :message is never used and Subject is specified in the mailto 
>>URI itself. So I think
>>
>>Also, Arnt has raised a good question about whether implementations are 
>>allowed to strip/alter garbage in :message or subject URI header. I 
>>think this should be addressed as well.
>>    
>>
>I agree on the MUST, because I can't think of reasons not to use the
>specified subject.  Concerning garbage: Broken MIME words are not garbage
>- they aren't MIME words, but ASCII data.
>
Correct.

>MIME words that contain odd
>characters are not garbage, either.  
>
I was thinking about embedded NULs, CRs and LFs.

>I don't see what could be a valid URI subject header, but not a valid
>mail subject header.  If there is something like that, the mailto URI
>draft should be changed.  Or MUST, for that matter. ;)
>  
>
>>I also have a new question. It might be a stupid one, but I will ask it 
>>anyway ;-). How References should be handled? Is the new message allowed 
>>to reference the original message? Are References: allowed as mailto URI 
>>headers?
>>    
>>
>That's two independent questions.  First the easy one, on URI references
>headers.  Could additional references hurt? I don't see why.  Say,
>I send someone a mail, and later notifications on triggering messages
>that refer to this mail - that may actually be useful, as they build
>a nice thread below the first mail.  We should allow that.
>
Exactly my thought.

>Should the triggering message set "In-reply-to:", thus ignoring an URI header of
>the same name? To me, it's not a reply, it is a notification.
>
Agreed.

Date: Thu, 03 Apr 2008 15:00:50 +0100
From: Alexey Melnikov <[email-masked]>
To: Barry Leiba <[email-masked]>
CC: [email-masked]
Subject: Re: Comments on draft-ietf-sieve-notify-mailto-07.txt
Sender: [email-masked]

(Speaking as the document shepherd.)

Barry Leiba wrote:

> I also have a more general question here:
> How did this (actually, the -06 version) manage to get to the IESG, 
> and into IETF Last Call?  I had no idea you were sending it yet, since 
> we'd talked about the -07 revision, and we clearly don't have WG 
> consensus on it.

Version -06 was accidentally sent to IETF LC, due to a wrong draft state 
in the ID tracker. Oh well.

> And things that I *did* think we had WG consensus are being revisited.

I didn't expect this either.

> We need to pull it back from the IESG, (re)establish WG consensus (and 
> explain why the PROTO writeup was wrong), and then send it back for a 
> fresh IETF Last Call.

I am not entirely sure that we need another IETF LC, but let's make this 
decision when the dust settles and the WG agrees on all changes.

Date: Thu, 03 Apr 2008 15:54:50 +0200
To: [email-masked]
Subject: Re: Comments on draft-ietf-sieve-notify-mailto-07.txt
From: Michael Haardt <[email-masked]>
Sender: [email-masked]

> Yes, if we know a reason why you might want to vary from what we recommend, it's 
> always a good idea to explain that.  But that's a side issue, and it doesn't 
> really matter.  The fact that we can't think of why you might want to... doesn't 
> mean that we should forbid it.

I guess the whole question is: Is it important to us to keep the
subject in case no other subject has been specified?

> Suppose (I'm groping, here, but bear with me) someone implements Sieve 
> notifications and sells it to a hospital.
> [privacy issue with passing subjects]

If privacy matters, then don't pass subjects to pagers.

Arnt pointed out that clients may be buggy.  And we all know, some have
a security problem with malware attachments.  If that means an RFC is
well advised to say you SHOULD NOT alter the content in transport, we
SHOULD keep the subject.  If the RFC is fine to ask you MUST NOT alter it,
knowing some sites do nevertheless to let their broken clients be safe,
we can do as well.

Perhaps this analogy helps to decide.

Michael

Date: Thu, 03 Apr 2008 14:36:31 +0100
From: Alexey Melnikov <[email-masked]>
To: Barry Leiba <[email-masked]>
CC: [email-masked]
Subject: Re: Comments on draft-ietf-sieve-notify-mailto-07.txt
Sender: [email-masked]

Barry Leiba wrote:

>> While using SHOULD here might be fine, not describing valid reasons for
>> violating the SHOULD when they are known in advance is a very bad 
>> thing. I
>> always prefer documents that explain background/motivation.
>
> ...
>
>> I read this as allowing an implementation to ignore :message and/or 
>> the Subject
>> URI header unconditionally. Is this something we actually want to 
>> encourage? I
>> certainly wouldn't want to.
>>
>> A much better approach is to at least explain what are valid reasons for
>> violating the SHOULD and optionally use MUSTs.
>
> No, no, no, no!
>
> Yes, if we know a reason why you might want to vary from what we 
> recommend, it's always a good idea to explain that.  But that's a side 
> issue, and it doesn't really matter.

Actually, it is the only thing that matters to me in this case.
I can live with either SHOULD or MUST, but now that I know about Arnt's 
issue, I can't live without its description ;-).

> The fact that we can't think of why you might want to... doesn't mean 
> that we should forbid it.
>
> Second, using SHOULD is *not* "encouraging" contrary behaviour.  Quite 
> the opposite: it's saying that if you don't have a damned good reason 
> for doing otherwise, this is the course you'd better take.

Well, if I see SHOULD in the spec *and* there is no explanation why 
SHOULD is there and it is very difficult for my implementation to 
conform to the SHOULD, then I don't feel bad about violating it.

But anyway, let's stop discussing this. It is not that important. And if 
you turn out to be wrong in the future, then I will point this out ;-).

Date: Thu, 03 Apr 2008 09:20:51 -0400
From: Barry Leiba <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: [email-masked]
Subject: Re: Comments on draft-ietf-sieve-notify-mailto-07.txt
Sender: [email-masked]

I also have a more general question here:
How did this (actually, the -06 version) manage to get to the IESG, and into IETF 
Last Call?  I had no idea you were sending it yet, since we'd talked about the 
-07 revision, and we clearly don't have WG consensus on it.  And things that I 
*did* think we had WG consensus are being revisited.

We need to pull it back from the IESG, (re)establish WG consensus (and explain 
why the PROTO writeup was wrong), and then send it back for a fresh IETF Last 
Call.

Barry

Date: Thu, 03 Apr 2008 09:16:58 -0400
From: Barry Leiba <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: [email-masked]
Subject: Re: Comments on draft-ietf-sieve-notify-mailto-07.txt
Sender: [email-masked]

> While using SHOULD here might be fine, not describing valid reasons for
> violating the SHOULD when they are known in advance is a very bad thing. I
> always prefer documents that explain background/motivation.
...
> I read this as allowing an implementation to ignore :message and/or the Subject
> URI header unconditionally. Is this something we actually want to encourage? I
> certainly wouldn't want to.
>
> A much better approach is to at least explain what are valid reasons for
> violating the SHOULD and optionally use MUSTs.

No, no, no, no!

Yes, if we know a reason why you might want to vary from what we recommend, it's 
always a good idea to explain that.  But that's a side issue, and it doesn't 
really matter.  The fact that we can't think of why you might want to... doesn't 
mean that we should forbid it.

Second, using SHOULD is *not* "encouraging" contrary behaviour.  Quite the 
opposite: it's saying that if you don't have a damned good reason for doing 
otherwise, this is the course you'd better take.

Suppose (I'm groping, here, but bear with me) someone implements Sieve 
notifications and sells it to a hospital.  And suppose the doctors use the 
notifications and start complaining that they get notifications with subjects 
like "Viagra Rx for Joe Jenkins", and they consider that a privacy problem 
because they have to leave their pagers at the door when they go to the ballet, 
and the ushers can see their notification messages.  But the Sieve implementors 
say, "But we have to do it that way because the notification spec says that we 
MUST use the subject from the original message."

Don't pick at that -- it's just an example.  The point is that we can't 
anticipate all the issues that might arise.  We can just say MUST when we're 
defining something that will break interoperability if it's not followed, and 
SHOULD or MAY otherwise.  For most of these fields, there's NO GOOD REASON to use 
MUST.  There just isn't.

So we SHOULDN'T.

Barry

Date: Thu, 03 Apr 2008 13:51:33 +0100
From: Alexey Melnikov <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
CC: [email-masked], Barry Leiba <[email-masked]>
Subject: Re: Comments on draft-ietf-sieve-notify-mailto-07.txt
Sender: [email-masked]

Arnt Gulbrandsen wrote:

> Alexey Melnikov writes:
>
>> Also, Arnt has raised a good question about whether implementations 
>> are allowed to strip/alter garbage in :message or subject URI header. 
>> I think this should be addressed as well.
>
> This text from 2119 describes what we want perfectly, IMO: "there may 
> exist valid reasons in particular circumstances to ignore a particular 
> item, but the full implications must be understood and carefully 
> weighed before choosing a different course."

While using SHOULD here might be fine, not describing valid reasons for 
violating the SHOULD when they are known in advance is a very bad thing. 
I always prefer documents that explain background/motivation.

Also, image that we update the text to read:

   o  The "Subject:" field of the notification message SHOULD contain the
      value defined by the :message notify tag, as described in
      [Notify].  If there is no :message tag and there is a "subject"
      header on the URI, then that value SHOULD be used.  If that is
      also absent, the subject SHOULD be retained from the triggering
      message.  Note that Sieve [Variables] can be used to advantage
      here, as shown in the example in Section 3.

I read this as allowing an implementation to ignore :message and/or the 
Subject URI header unconditionally. Is this something we actually want 
to encourage? I certainly wouldn't want to.

A much better approach is to at least explain what are valid reasons for 
violating the SHOULD and optionally use MUSTs.

Date: Thu, 03 Apr 2008 14:41:06 +0200
To: [email-masked]
Subject: Re: Comments on draft-ietf-sieve-notify-mailto-07.txt
From: Michael Haardt <[email-masked]>
Sender: [email-masked]

> In section 2.7:
>
>    o  The "To:" header field and the envelope recipient(s) of the
>       notification message SHOULD be set to the address(es) specified in
>       the URI (including any URI headers where the hname is "to").
>
>
> I think there is a problem with this text. Surely the envelope recipient 
> is specified in the mailto URI itself, not in the to URI header. (Your 
> example in section 3 confirms that.) For example if mailto URI is 
> "mailto:[email-masked]?to=[email-masked]", then the 
> envelope recipient is [email-masked] and not 
> [email-masked].
>
> I think the text is also trying to say that both To: header and envelope 
> to should be set to the same value.

To me, the text is correct.  From draft-duerst-mailto-bis-05, section 2.:

   Also note that it is legal to specify both <to> and an <hfname> whose
   value is "to".  That is,

   <mailto:[email-masked][email-masked]>

   is equivalent to

   <mailto:?to=[email-masked][email-masked]>

   is equivalent to

   <mailto:[email-masked]?to=[email-masked]>

The text asks for both header and envelope recipients to be set to
the recipients specified in the URI, and reminds the reader that
URIs may contain recipients as URI headers, too.

>    o  The "Subject:" field of the notification message MUST contain the
>       value defined by the :message notify tag, as described in
>       [Notify].  If there is no :message tag and there is a "subject"
>       header on the URI, then that value SHOULD be used.
>
>
> I think this SHOULD should be upgraded to a MUST. Reason: I can see use 
> cases when :message is never used and Subject is specified in the mailto 
> URI itself. So I think
>
> Also, Arnt has raised a good question about whether implementations are 
> allowed to strip/alter garbage in :message or subject URI header. I 
> think this should be addressed as well.

I agree on the MUST, because I can't think of reasons not to use the
specified subject.  Concerning garbage: Broken MIME words are not garbage
- they aren't MIME words, but ASCII data.  MIME words that contain odd
characters are not garbage, either.

I don't see what could be a valid URI subject header, but not a valid
mail subject header.  If there is something like that, the mailto URI
draft should be changed.  Or MUST, for that matter. ;)

> I also have a new question. It might be a stupid one, but I will ask it 
> anyway ;-). How References should be handled? Is the new message allowed 
> to reference the original message? Are References: allowed as mailto URI 
> headers?

That's two independent questions.  First the easy one, on URI references
headers.  Could additional references hurt? I don't see why.  Say,
I send someone a mail, and later notifications on triggering messages
that refer to this mail - that may actually be useful, as they build
a nice thread below the first mail.  We should allow that.  Should the
triggering message set "In-reply-to:", thus ignoring an URI header of
the same name? To me, it's not a reply, it is a notification.

Not as easy: Should notifications, and that's a general question
beyond the scope of mail, reference to the triggering message, if
the notification method allows to give references? That's an issue of
draft-ietf-sieve-notify, and a good one.  I like the idea.

Ask more questions like that, and nobody will even think of a last call
on notify for quite some time. ;-)

Michael

Date: Thu, 3 Apr 2008 14:00:54 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Comments on draft-ietf-sieve-notify-mailto-07.txt
Cc: Alexey Melnikov <[email-masked]>, Barry Leiba <[email-masked]>
Sender: [email-masked]

Alexey Melnikov writes:
> Also, Arnt has raised a good question about whether implementations 
> are allowed to strip/alter garbage in :message or subject URI header. 
> I think this should be addressed as well.

This text from 2119 describes what we want perfectly, IMO: "there may 
exist valid reasons in particular circumstances to ignore a particular 
item, but the full implications must be understood and carefully 
weighed before choosing a different course."

Arnt

Date: Thu, 03 Apr 2008 11:19:41 +0100
From: Alexey Melnikov <[email-masked]>
To: Barry Leiba <[email-masked]>
CC: [email-masked]
Subject: Comments on draft-ietf-sieve-notify-mailto-07.txt
Sender: [email-masked]

Hi Barry,
Let me try to rephrase my personal objections regarding some specific cases of using SHOULD in the latest draft.

In section 2.7:

   o  The "To:" header field and the envelope recipient(s) of the
      notification message SHOULD be set to the address(es) specified in
      the URI (including any URI headers where the hname is "to").

I think there is a problem with this text. Surely the envelope recipient 
is specified in the mailto URI itself, not in the to URI header. (Your 
example in section 3 confirms that.) For example if mailto URI is 
"mailto:[email-masked]?to=[email-masked]", then the 
envelope recipient is [email-masked] and not 
[email-masked].

I think the text is also trying to say that both To: header and envelope 
to should be set to the same value.

So, I suggest the paragraph is split into 2 paragraphs to separately 
specify requirements on To: and envelope recipient.

   o  The "Subject:" field of the notification message MUST contain the
      value defined by the :message notify tag, as described in
      [Notify].  If there is no :message tag and there is a "subject"
      header on the URI, then that value SHOULD be used.

I think this SHOULD should be upgraded to a MUST. Reason: I can see use 
cases when :message is never used and Subject is specified in the mailto 
URI itself. So I think

Also, Arnt has raised a good question about whether implementations are 
allowed to strip/alter garbage in :message or subject URI header. I 
think this should be addressed as well.

I also have a new question. It might be a stupid one, but I will ask it 
anyway ;-). How References should be handled? Is the new message allowed 
to reference the original message? Are References: allowed as mailto URI 
headers?

**

Date: Wed, 02 Apr 2008 22:42:35 +0200
To: [email-masked]
Subject: Re: [Fwd: Re: [secdir] secdir review of draft-ietf-sieve-notify-mailto-07.txt]
From: Michael Haardt <[email-masked]>
Sender: [email-masked]

> >"Fixed" does indeed not hit the point, but do you have a better
> >suggestion?
> >
> >The idea was to allow the system to used a fixed address, or a fixed
> >addressing scheme, no matter if the variable part is a RFC subadressing
> >detail or some other kind of subadressing, that can be recognised as such,
> >telling the mail "comes from the notification system".  The quoted part
> >tells exactly what was tried to express.  I would appreciate a better
> >wording, but can't think of any.
> >  
> >
> I think the following would be better:
>
>  or to an email address associated with the notification system
>
> This avoids the argument about whether there is a single addresse, whether it must be completely static, etc.

Perfect, thanks!

Michael

Date: Wed, 02 Apr 2008 21:27:47 +0100
From: Alexey Melnikov <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
CC: [email-masked]
Subject: Re: [Fwd: Re: [secdir] secdir review of draft-ietf-sieve-notify-mailto-07.txt]
Sender: [email-masked]

Arnt Gulbrandsen wrote:

> Alexey Melnikov writes:
>
>> Arnt Gulbrandsen wrote:
>>
>>> If the original subject is invalid in some way I wouldn't respond in 
>>> kind.
>>
>> Can you clarify?
>
> You thought the syntax of Subject is simple enough for everyone?
>
> Some MTAs will give you a Subject field that contains null bytes, BELs 
> and other stuff that really should be encoded.

MTAs doing that are simply broken.

Now, if a user used encoded-character to specify such garbage in the 
:message value, that is another story. Hmm, I think we need to 
specifically allow implementations to alter Subject in such cases.

> If the sender uses crapware, you can get a Subject field that contains 
> encoded-words, but the encoded-words are just wrong, and the rules in 
> RFC 2047 don't produce the result users want.
>
>     Subject: =?iso-8859-1?q?Are you there, Alexey??=
>
> Those are from clueless but innocent senders. Nasty senders can give 
> you this and worse:
>
>     Subject: =?us-ascii?q?=0D=0A=0D=0DBody=? text?
>
> There's more. If you want I can dig through our test messages. But 
> these examples should be enough.
>
> In these well-considered cases, I would do something other than what 
> the mailto-notify document says, and I think I'd be right, so SHOULD 
> seems better than MUST to my eyes. But as I said, I don't object to 
> MUST. MUST is about valid input, and at least two of those three 
> examples aren't valid.

Exactly (last sentence). And the MUST doesn't tell anything about encodings.

>>>>> The part that reads:
>>>>>
>>>>>      If ":from" is not specified or is not valid, the envelope 
>>>>>      sender      of the notification message SHOULD be set either 
>>>>>      to the envelope "to" field from the triggering message, as 
>>>>>      used by Sieve, or to a fixed email address (so it "comes from 
>>>>>      the      notification system"), at the discretion of the      
>>>>> implementation.
>>>>>
>>>>> already list all possible alternatives, so I don't think it is a 
>>>>> SHOULD either.
>>>>
>>> Those aren't all possible alternatives, so although I don't mind 
>>> MUST I rather like keeping SHOULD. (One other alternative is a 
>>> system address with a single-use subaddress.)
>>
>> Ok, you and Barry have convinced me that this SHOULD is fine.
>> Also, how about deleting the word "fixed" above?
>
> Fine.

I believe I've already suggested a better replacement for this in 
another message.

Date: Wed, 02 Apr 2008 21:25:17 +0100
From: Alexey Melnikov <[email-masked]>
To: Barry Leiba <[email-masked]>
CC: [email-masked]
Subject: Re: secdir review of draft-ietf-sieve-notify-mailto-07.txt
Sender: [email-masked]

Barry Leiba wrote:

>> Folks, Cyrus and I as chairs need more feedback on whether SHOULDs 
>> need to be changed to MUSTs. See my forwarded reply.
>
> Alexey didn't forward my response to Hannes's review, so here's the 
> relevant part of it:

Mea culpa.

> --------------------------------------------------------
> On the SHOULD vs MUST list, Alexey has actually had the same 
> questions.  It's a clarification I've recently put in, because the 
> text had said "is" (as in, "If the mailto URI contains a "body" 
> header, the value of that header is used as the body of the 
> notification message.")
>
> I considered it this way:  In cases where it seemed that it really 
> matters -- that some sense of interoperability of notifications is 
> affected -- I used MUST. Otherwise, I used SHOULD or MAY.  In other 
> words, I tried to avoid using MUST, where MUST wasn't necessary.
>
> Alexey commented to me that it seemed to him that if there was no 
> other reasonable choice, we ought to have MUST.  On the other hand, it 
> seems to me that if there's not a *reason* for MUST, we ought to leave 
> the choice to the implementor (or to whoever configures the system, or 
> whatever), rather than being needlessly specific about something that 
> really doesn't matter.
> --------------------------------------------------------
>
> I'm willing to change to MUST (obviously, I will if that's the WG 
> consensus), but my strong sense is that it's wrong to prescribe 
> behaviour that doesn't matter.  For Sieve notifications, it seems to 
> me that "interoperability" means that one can move a script to another 
> Sieve implementation and get reasonably consistent results in the 
> notifications, such that the user would have a substantially similar 
> experience.

Agreed.

> My sense, there, is that what matters most is the subject of the 
> message, so that's the only MUST (apart from Auto-Submitted, which has 
> a functional purpose).

That make sense.

I would also add SMTP MAIL FROM to this category, as it is frequently 
used for Sieve filtering.

> The other part that's probably important is the body, but there are 
> various reasons for an implementation to want to control the body -- 
> security configuration, notification infrastructure, whatever.

Ok. I wish you added some text to the document stating that. This would 
remove any further questions why it is only a SHOULD.

I wasn't entirely clear of why you chose SHOULD in various places, so 
thanks for clarifying.

> So that's a SHOULD.
>
> In particular, I don't agree with Alexey's thought that if WE can't 
> think of an alternative value for a field, our advice should be MUST.

I would slightly reword this: when using SHOULD one should have an 
example or at least gut feeling of when it can't be violated.

> I much prefer the other approach: if there's not a compelling reason 
> for MUST, make it SHOULD and let the implementation determine whether 
> there's a good reason not to comply with that (remember the meaning of 
> SHOULD).

It is a bit silly to argue this in general case. I would rephrase my 
objections based on the guiding principal you've specified above.

> I normally don't like SHOULD in protocols.  This is a case where I 
> think SHOULD is entirely appropriate.

Subject: Re: [Fwd: Re: [secdir] secdir review of draft-ietf-sieve-notify-mailto-07.txt]
From: Kjetil Torgrim Homme <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]
Date: Wed, 02 Apr 2008 15:47:07 +0200
Sender: [email-masked]

On Wed, 2008-04-02 at 13:05 +0100, Alexey Melnikov wrote:
> Michael Haardt wrote:
> >The idea was to allow the system to used a fixed address, or a fixed
> >addressing scheme, no matter if the variable part is a RFC subadressing
> >detail or some other kind of subadressing, that can be recognised as such,
> >telling the mail "comes from the notification system".  The quoted part
> >tells exactly what was tried to express.  I would appreciate a better
> >wording, but can't think of any.
> 
> I think the following would be better:
> 
>  or to an email address associated with the notification system
> 
> This avoids the argument about whether there is a single addresse,
> whether it must be completely static, etc.

this is *exactly* what I was going to suggest myself :-)

-- 
best wishes,
Kjetil T.

Date: Wed, 02 Apr 2008 09:36:08 -0400
From: Barry Leiba <[email-masked]>
To: SIEVE <[email-masked]>
Subject: OT: Conference on Email and Anti-Spam final call for papers
Sender: [email-masked]

This seems sufficiently on-topic for this list:
The 2008 Conference on Email and Anti-Spam submission deadline is=20
approaching, and has been extended by a week, to 10 April.  If you have=20
any work to report on in the area of Internet messaging abuse and its=20
prevention =97 not limited to email spam; see the topic list in the CfP, =

below =97 please form it into a paper by next week, and submit it.

Barry

----------------------------------------------------------------------
       THE FIFTH CONFERENCE ON EMAIL AND ANTI-SPAM (CEAS 2008)

             Thursday August 21 and Friday August 22, 2008
                    Microsoft Research Silicon Valley
                       Mountain View, California
                         <http://www.ceas.cc>

                        FINAL CALL FOR PAPERS

The Conference on Email and Anti-Spam (CEAS) invites the submission
of papers for its fifth meeting. Papers are invited on all aspects of
electronic communication including email, instant messaging, text
messaging, and voice over internet protocol (VoIP). Topics of interest
include novel applications of electronic messaging, abatement of abuses
of electronic messaging, spam, spit (spam over internet telephony), spim
(spam over instant messenger), phishing, identity theft via messaging,
viruses, and spyware.

Paper submissions can be either research papers, extended abstracts,
industry reports, or law and policy papers. Submissions from
practitioners and vendors are encouraged. Papers will be selected by
peer review for presentation at CEAS 2008. Papers will be reviewed based
on their contribution to the literature.

SUGGESTED TOPICS:

*  Message filtering, blocking, authentication
    -  Machine learning
    -  Natural language processing
    -  Adversarial learning
    -  Challenge-response
    -  Payment schemes
    -  Disposable addresses
    -  Messaging protocols
    -  Digital signatures
*  Evaluation
    - Corpus and benchmark creation
    - Measures and methodologies
    - Comparative tests of methods or products
*  Analysis
    - Economics of spam, spit, spim, phishing, etc.
    - Abuse tactics and patterns
    - Legitimate use patterns
    - Historical data
*  Message organization and search
    - Advanced calendaring and scheduling
    - Automatic foldering
    - Automatic routing
    - Summarization
    - Search
*  Systems and network issues
    - Performance & scalability
    - Reliability & security
    - Archival & retrieval
*  User issues
    - User interfaces
    - Usability studies
    - Messaging in support of user activities
*  Social issues
    - Deducing social networks
    - Costs and benefits of messaging use and abuse
    - Other social impacts
*  Industry
    - Cooperation for stopping abuse
    - Messaging and abuse reporting standards
    - Interoperability
*  Legal issues
    - Spam, spit, spim and phishing, etc.
    - Identity theft
    - Privacy
    - Freedom of speech
    - Digital rights management

KEY DATES:

*  Submission deadline: April 10, 2008 (10:59pm UTC) -- EXTENDED DATE
*  Notification of acceptance: June 6, 2008.
*  Final camera-ready version of papers: June 21, 2008
*  Conference: August 21 and 22, 2008

REQUIREMENTS:

Papers may be of one of two types:
*  Extended abstracts (up to 2 pages) may outline work in progress,
    exceptional papers published for different scientific communities,
    original research, or industry reports.
*  Full papers (up to 10 pages). Work may not have been previously
    published in, or under consideration for publication in any other
    conference or journal.

Submissions must use the CEAS electronic system at:
https://cmt.research.microsoft.com/CEAS2008/. The style for
submissions and final papers is a two-column, 8.5 by 11 inch format. See
http://www.ceas.cc/2008/format.htm for details.

Papers will be reviewed by a committee of experts from academic and
industrial research centers. Accepted papers will be made freely
available on the web, and will be published on CD-ROM. Authors will
retain copyright of their work.

CONTACT:

*  The conference chair and co-chairs can be reached at
    [email-masked]

CEAS PRESIDENT

*  Gordon Cormack
    University of Waterloo
    http://plg.uwaterloo.ca/~gvcormac/

GENERAL CONFERENCE CHAIR:

*  Aleksander Kolcz
    Microsoft Live Labs
    http://ir.iit.edu/~alek/

PROGRAM CO-CHAIRS:

*  Andrej Bratko
    Jozef Stefan Institute
    http://ai.ijs.si/andrej/

*  Barry Leiba
    IBM Research
    http://www.research.ibm.com/people/l/leiba/

*  Tobias Scheffer
    Max Planck Institute for Computer Science
    http://www.mpi-inf.mpg.de/~scheffer/
----------------------------------------------------------------------

Date: Wed, 02 Apr 2008 13:05:17 +0100
From: Alexey Melnikov <[email-masked]>
To: Michael Haardt <[email-masked]>
CC: [email-masked]
Subject: Re: [Fwd: Re: [secdir] secdir review of draft-ietf-sieve-notify-mailto-07.txt]
Sender: [email-masked]

Michael Haardt wrote:

>>>>>     If ":from" is not specified or is not valid, the envelope 
>>>>>sender      of the notification message SHOULD be set either to the 
>>>>>     envelope "to" field from the triggering message, as used by 
>>>>>     Sieve, or to a fixed email address (so it "comes from the      
>>>>>notification system"), at the discretion of the implementation.
>>>>>
>>>>>already list all possible alternatives, so I don't think it is a 
>>>>>SHOULD either.
>>>>>          
>>>>>
>>>Those aren't all possible alternatives, so although I don't mind MUST 
>>>I rather like keeping SHOULD. (One other alternative is a system 
>>>address with a single-use subaddress.)
>>>      
>>>
>>Ok, you and Barry have convinced me that this SHOULD is fine.
>>Also, how about deleting the word "fixed" above?
>>    
>>
>"Fixed" does indeed not hit the point, but do you have a better
>suggestion?
>
>The idea was to allow the system to used a fixed address, or a fixed
>addressing scheme, no matter if the variable part is a RFC subadressing
>detail or some other kind of subadressing, that can be recognised as such,
>telling the mail "comes from the notification system".  The quoted part
>tells exactly what was tried to express.  I would appreciate a better
>wording, but can't think of any.
>  
>
I think the following would be better:

 or to an email address associated with the notification system

This avoids the argument about whether there is a single addresse, whether it must be completely static, etc.

>It is definitively a SHOULD, if we can't even specify it sharply.
>  
>
Agreed.

Date: Wed, 2 Apr 2008 10:15:42 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: [Fwd: Re: [secdir] secdir review of draft-ietf-sieve-notify-mailto-07.txt]
Cc: Alexey Melnikov <[email-masked]>
Sender: [email-masked]

Alexey Melnikov writes:
> Arnt Gulbrandsen wrote:
>> If the original subject is invalid in some way I wouldn't respond in kind.
>
> Can you clarify?

You thought the syntax of Subject is simple enough for everyone?

Some MTAs will give you a Subject field that contains null bytes, BELs 
and other stuff that really should be encoded.

If the sender uses crapware, you can get a Subject field that contains 
encoded-words, but the encoded-words are just wrong, and the rules in 
RFC 2047 don't produce the result users want.

     Subject: =?iso-8859-1?q?Are you there, Alexey??=

Those are from clueless but innocent senders. Nasty senders can give you 
this and worse:

     Subject: =?us-ascii?q?=0D=0A=0D=0DBody=? text?

There's more. If you want I can dig through our test messages. But these 
examples should be enough.

In these well-considered cases, I would do something other than what the 
mailto-notify document says, and I think I'd be right, so SHOULD seems 
better than MUST to my eyes. But as I said, I don't object to MUST. 
MUST is about valid input, and at least two of those three examples 
aren't valid.

>>>> The part that reads:
>>>>
>>>>      If ":from" is not specified or is not valid, the envelope 
>>>>      sender      of the notification message SHOULD be set either 
>>>>      to the envelope "to" field from the triggering message, as 
>>>>      used by Sieve, or to a fixed email address (so it "comes from 
>>>>      the      notification system"), at the discretion of the 
>>>>      implementation.
>>>>
>>>> already list all possible alternatives, so I don't think it is a 
>>>> SHOULD either.
>>
>> Those aren't all possible alternatives, so although I don't mind MUST 
>> I rather like keeping SHOULD. (One other alternative is a system 
>> address with a single-use subaddress.)
>
> Ok, you and Barry have convinced me that this SHOULD is fine.
> Also, how about deleting the word "fixed" above?

Fine.

Arnt

Date: Wed, 02 Apr 2008 10:15:41 +0200
To: [email-masked]
Subject: Re: [Fwd: Re: [secdir] secdir review of draft-ietf-sieve-notify-mailto-07.txt]
From: Michael Haardt <[email-masked]>
Sender: [email-masked]

> >>>      If ":from" is not specified or is not valid, the envelope 
> >>> sender      of the notification message SHOULD be set either to the 
> >>>      envelope "to" field from the triggering message, as used by 
> >>>      Sieve, or to a fixed email address (so it "comes from the      
> >>> notification system"), at the discretion of the implementation.
> >>>
> >>> already list all possible alternatives, so I don't think it is a 
> >>> SHOULD either.
> >>
> > Those aren't all possible alternatives, so although I don't mind MUST 
> > I rather like keeping SHOULD. (One other alternative is a system 
> > address with a single-use subaddress.)
>
> Ok, you and Barry have convinced me that this SHOULD is fine.
> Also, how about deleting the word "fixed" above?

"Fixed" does indeed not hit the point, but do you have a better
suggestion?

The idea was to allow the system to used a fixed address, or a fixed
addressing scheme, no matter if the variable part is a RFC subadressing
detail or some other kind of subadressing, that can be recognised as such,
telling the mail "comes from the notification system".  The quoted part
tells exactly what was tried to express.  I would appreciate a better
wording, but can't think of any.

It is definitively a SHOULD, if we can't even specify it sharply.

Michael

Date: Tue, 01 Apr 2008 20:19:23 +0100
From: Alexey Melnikov <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
CC: [email-masked]
Subject: Re: [Fwd: Re: [secdir] secdir review of draft-ietf-sieve-notify-mailto-07.txt]
Sender: [email-masked]

Arnt Gulbrandsen wrote:

> Alexey Melnikov writes:
>
>> Folks, Cyrus and I as chairs need more feedback on whether SHOULDs 
>> need to be changed to MUSTs. See my forwarded reply.
>
> I don't mind making these MUST.
>
> Except that I do just a little, but I'd wiggle even in case of MUST. 
> Details below.
>
>>>>   o  The "Subject:" field of the notification message MUST
>>>
> ...
> If I were to implement notify-mailto, my code might use different RFC 
> 2047 encoding.

This doesn't contradict the MUST, as it says nothing about encodings.

> If the original subject is invalid in some way I wouldn't respond in kind.

Can you clarify?

>>> The part that reads:
>>>
>>>      If ":from" is not specified or is not valid, the envelope 
>>> sender      of the notification message SHOULD be set either to the 
>>>      envelope "to" field from the triggering message, as used by 
>>>      Sieve, or to a fixed email address (so it "comes from the      
>>> notification system"), at the discretion of the implementation.
>>>
>>> already list all possible alternatives, so I don't think it is a 
>>> SHOULD either.
>>
> Those aren't all possible alternatives, so although I don't mind MUST 
> I rather like keeping SHOULD. (One other alternative is a system 
> address with a single-use subaddress.)

Ok, you and Barry have convinced me that this SHOULD is fine.
Also, how about deleting the word "fixed" above?

Date: Mon, 31 Mar 2008 23:41:29 +0100
From: Alexey Melnikov <[email-masked]>
To: Patrick Ben Koetter <[email-masked]>
CC: [email-masked]
Subject: Re: Standard to selectively disable rules in sieve script?
Sender: [email-masked]

Hi Patrick,

Patrick Ben Koetter wrote:

>* Nigel Swinson <[email-masked]>:
>  
>
>>>for the case of temporarily disabling a rule,  I think the most obvious
>>>method is a simple
>>>
>>>   if false { }
>>>
>>>around the block.  that construct can hardly be used for anything else.
>>>using comments is bad, since comments should be truly freeform and
>>>without meaning.
>>>      
>>>
>>Agreed, and this is actually what I chose to do with our implementation.  It
>>has the added advantage of still doing compilation/syntax checking on the
>>disabled rule, whereas if it was just commented out it'll all be ignored...
>>    
>>
>It seems that there's an agreement on temporarily disabling a rule.
>People should use:
>
>        if false { }
>
>
>I am fairly new to this list and not accustomed with its procedures. What
>would I have to do to propose this agreement to become a standard?  
>
You need to write a short IETF draft on this and then get it published 
as an RFC.
Contact me off-list if you need to know more details.