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

[Tony Hansen <[e-mail]>]

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

Alexey Melnikov wrote:
> 
> Arnt Gulbrandsen wrote:
> 
>> Alexey Melnikov <[e-mail]>
>>  
>>
>>> Elaborate on how this can be done with Sieve variables, or elaborate on
>>> extracting attachements in general?
>>>   
>> How it would be done, the role of :url, and why :url makes this
>> easier/possible.
>>  
>>
> 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?
> 




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m415tvYr014934 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Apr 2008 22:55:57 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m415tvBV014933; Wed, 30 Apr 2008 22:55:57 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail121.messagelabs.com (mail121.messagelabs.com [216.82.241.195]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m415ttBv014924 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Wed, 30 Apr 2008 22:55:56 -0700 (MST) (envelope-from [e-mail])
X-VirusChecked: Checked
X-Env-Sender: [e-mail]
X-Msg-Ref: server-12.tower-121.messagelabs.com!1209621354!27377889!1
X-StarScan-Version: 5.5.12.14.2; banners=-,-,-
X-Originating-IP: [144.160.20.54]
Received: (qmail 23024 invoked from network); 1 May 2008 05:55:54 -0000
Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-12.tower-121.messagelabs.com with AES256-SHA encrypted SMTP; 1 May 2008 05:55:54 -0000
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m415tsZ9000749 for <[e-mail]>; Thu, 1 May 2008 01:55:54 -0400
Received: from alph001.aldc.att.com (alph001.aldc.att.com [135.53.7.26]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m415tkTL000739 for <[e-mail]>; Thu, 1 May 2008 01:55:47 -0400
Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alph001.aldc.att.com (8.14.0/8.14.0) with ESMTP id m415tkev003445 for <[e-mail]>; Thu, 1 May 2008 01:55:46 -0400
Received: from maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by alph001.aldc.att.com (8.14.0/8.14.0) with ESMTP id m415timW003442 for <[e-mail]>; Thu, 1 May 2008 01:55:44 -0400
Received: from [135.210.32.26] (unknown[135.210.32.26](misconfigured sender)) by maillennium.att.com (mailgw1) with ESMTP id <20080501055543gw100l7orbe> (Authid: tony); Thu, 1 May 2008 05:55:44 +0000
Message-ID: <[e-mail]>
Date: Thu, 01 May 2008 01:56:59 -0400
From: Tony Hansen <[e-mail]>
User-Agent: Thunderbird 2.0.0.12 (Windows/20080213)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: MIME loops: Extracting attachment to disk and replacing it with an URL
References: <[e-mail]>            <[e-mail]>            <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.95.6
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

Alexey Melnikov wrote:
> 
> Arnt Gulbrandsen wrote:
> 
>> Alexey Melnikov <[e-mail]>
>>  
>>
>>> Elaborate on how this can be done with Sieve variables, or elaborate on
>>> extracting attachements in general?
>>>   
>> How it would be done, the role of :url, and why :url makes this
>> easier/possible.
>>  
>>
> 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?
> 



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m3UMA1pM017335 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Apr 2008 15:10:01 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m3UMA1AT017332; Wed, 30 Apr 2008 15:10:01 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m3UM9xU2017302 for <[e-mail]>; Wed, 30 Apr 2008 15:10:00 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 30) id F13563A6DB0; Wed, 30 Apr 2008 15:09:55 -0700 (PDT)
X-idtracker: yes
To: IETF-Announce <[e-mail]>
From: The IESG <[e-mail]>
Subject: Last Call: draft-ietf-sieve-editheader (Sieve Email Filtering:  Editheader Extension) to Proposed Standard 
Reply-to: [e-mail]
CC: <[e-mail]>
Message-Id: <[e-mail]>
Date: Wed, 30 Apr 2008 15:09:55 -0700 (PDT)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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
[e-mail] mailing lists by 2008-05-14. Exceptionally, 
comments may be sent to [e-mail] 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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m3NB4t3u051779 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Apr 2008 04:04:55 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m3NB4tWs051778; Wed, 23 Apr 2008 04:04:55 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m3NB4rMW051771 for <[e-mail]>; Wed, 23 Apr 2008 04:04:53 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.125] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Wed, 23 Apr 2008 12:04:52 +0100
Message-ID: <[e-mail]>
Date: Wed, 23 Apr 2008 12:04:38 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: [e-mail]
Subject: WGLC on IMAP Sieve (draft-ietf-lemonade-imap-sieve)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m3NAOulc048055 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Apr 2008 03:24:56 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m3NAOuSs048053; Wed, 23 Apr 2008 03:24:56 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m3NAOr7L048044 for <[e-mail]>; Wed, 23 Apr 2008 03:24:55 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.125] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Wed, 23 Apr 2008 11:24:51 +0100
Message-ID: <[e-mail]>
Date: Wed, 23 Apr 2008 09:32:26 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Michael Haardt <[e-mail]>
CC: [e-mail]
Subject: Re: Comments on draft-ietf-sieve-notify-mailto-07.txt
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m3M8lRCe090469 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Apr 2008 01:47:27 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m3M8lRZl090468; Tue, 22 Apr 2008 01:47:27 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mout0.freenet.de (mout0.freenet.de [IPv6:2001:748:100:40::2:2]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m3M8lPwt090452 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 22 Apr 2008 01:47:26 -0700 (MST) (envelope-from [e-mail])
Received: from [195.4.92.15] (helo=5.mx.freenet.de) by mout0.freenet.de with esmtpa (Exim 4.69) (envelope-from <[e-mail]>) id 1JoE9t-0003X7-7J for [e-mail]; Tue, 22 Apr 2008 10:47:25 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]:46614) by 5.mx.freenet.de with esmtps (TLSv1:AES256-SHA:256) (port 25) (Exim 4.69 #12) id 1JoE9t-0001Xp-6d for [e-mail]; Tue, 22 Apr 2008 10:47:25 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.69 #18) id 1JoE9s-0001tv-Gu for [e-mail]; Tue, 22 Apr 2008 10:47:24 +0200
Date: Tue, 22 Apr 2008 10:47:24 +0200
To: [e-mail]
Subject: Re: editheader interaction with mailto notifications
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
User-Agent: Heirloom mailx 12.1 6/15/06
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
From: Michael Haardt <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> > 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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m3M8TJnG088586 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Apr 2008 01:29:19 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m3M8TJ4q088585; Tue, 22 Apr 2008 01:29:19 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mout0.freenet.de (mout0.freenet.de [IPv6:2001:748:100:40::2:2]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m3M8THks088575 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 22 Apr 2008 01:29:18 -0700 (MST) (envelope-from [e-mail])
Received: from [195.4.92.18] (helo=8.mx.freenet.de) by mout0.freenet.de with esmtpa (Exim 4.69) (envelope-from <[e-mail]>) id 1JoDsK-0002Es-Mq for [e-mail]; Tue, 22 Apr 2008 10:29:16 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]:35067) by 8.mx.freenet.de with esmtps (TLSv1:AES256-SHA:256) (port 25) (Exim 4.69 #12) id 1JoDsK-0006ta-M3 for [e-mail]; Tue, 22 Apr 2008 10:29:16 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.69 #18) id 1JoDsK-0001t9-Cc for [e-mail]; Tue, 22 Apr 2008 10:29:16 +0200
Date: Tue, 22 Apr 2008 10:29:16 +0200
To: [e-mail]
Subject: Re: Comments on draft-ietf-sieve-notify-mailto-07.txt
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
User-Agent: Heirloom mailx 12.1 6/15/06
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
From: Michael Haardt <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> > 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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m3M88T5e087011 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Apr 2008 01:08:29 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m3M88TRR087010; Tue, 22 Apr 2008 01:08:29 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mout3.freenet.de (mout3.freenet.de [IPv6:2001:748:100:40::2:5]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m3M88RV5086999 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 22 Apr 2008 01:08:28 -0700 (MST) (envelope-from [e-mail])
Received: from [195.4.92.17] (helo=7.mx.freenet.de) by mout3.freenet.de with esmtpa (Exim 4.69) (envelope-from <[e-mail]>) id 1JoDYA-0000Cp-5A for [e-mail]; Tue, 22 Apr 2008 10:08:26 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]:53718) by 7.mx.freenet.de with esmtps (TLSv1:AES256-SHA:256) (port 25) (Exim 4.69 #12) id 1JoDYA-0002fL-4W for [e-mail]; Tue, 22 Apr 2008 10:08:26 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.69 #18) id 1JoDY9-0001sQ-P1 for [e-mail]; Tue, 22 Apr 2008 10:08:25 +0200
Date: Tue, 22 Apr 2008 10:08:25 +0200
To: [e-mail]
Subject: Re: Comments on draft-ietf-sieve-notify-mailto-07.txt
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
User-Agent: Heirloom mailx 12.1 6/15/06
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
From: Michael Haardt <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m3M7qeR7085928 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Apr 2008 00:52:40 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m3M7qeZI085927; Tue, 22 Apr 2008 00:52:40 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mout0.freenet.de (mout0.freenet.de [IPv6:2001:748:100:40::2:2]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m3M7qchh085920 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 22 Apr 2008 00:52:39 -0700 (MST) (envelope-from [e-mail])
Received: from [195.4.92.22] (helo=12.mx.freenet.de) by mout0.freenet.de with esmtpa (Exim 4.69) (envelope-from <[e-mail]>) id 1JoDIr-0003i1-Pm for [e-mail]; Tue, 22 Apr 2008 09:52:37 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]:45157) by 12.mx.freenet.de with esmtps (TLSv1:AES256-SHA:256) (port 25) (Exim 4.69 #12) id 1JoDIr-0006JM-Ox for [e-mail]; Tue, 22 Apr 2008 09:52:37 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.69 #18) id 1JoDIr-0001rk-Fn for [e-mail]; Tue, 22 Apr 2008 09:52:37 +0200
Date: Tue, 22 Apr 2008 09:52:37 +0200
To: [e-mail]
Subject: Re: [Fwd: Re: [secdir] secdir review of draft-ietf-sieve-notify-mailto-07.txt]
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
User-Agent: Heirloom mailx 12.1 6/15/06
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
From: Michael Haardt <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m3LJoxBu023596 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Apr 2008 12:50:59 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m3LJox9E023595; Mon, 21 Apr 2008 12:50:59 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m3LJotxs023584 for <[e-mail]>; Mon, 21 Apr 2008 12:50:56 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Mon, 21 Apr 2008 20:50:54 +0100
Message-ID: <[e-mail]>
Date: Mon, 21 Apr 2008 20:50:05 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Arnt Gulbrandsen <[e-mail]>
CC: [e-mail]
Subject: Re: MIME loops: Extracting attachment to disk and replacing it with an URL
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Arnt Gulbrandsen wrote:

>Alexey Melnikov <[e-mail]>
>  
>
>>Elaborate on how this can be done with Sieve variables, or elaborate on
>>extracting attachements in general?
>>    
>>
>How it would be done, the role of :url, and why :url makes this
>easier/possible.
>  
>
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?



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m3LGMO62090867 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Apr 2008 09:22:24 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m3LGMOWF090866; Mon, 21 Apr 2008 09:22:24 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from boole.openldap.org (boole.openldap.org [IPv6:2001:4f8:3:ba:2e0:18ff:fe02:efec]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m3LGMNjW090859 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 21 Apr 2008 09:22:24 -0700 (MST) (envelope-from [e-mail])
Received: from [192.168.1.197] (75-141-230-206.dhcp.nv.charter.com [75.141.230.206] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.13.8/8.13.8) with ESMTP id m3LGMDwY027790 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 21 Apr 2008 16:22:15 GMT (envelope-from [e-mail])
Cc: [e-mail]
Message-Id: <[e-mail]>
From: Kurt Zeilenga <[e-mail]>
To: "Mark E. Mallett" <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v919.2)
Subject: Re: editheader interaction with mailto notifications
Date: Mon, 21 Apr 2008 09:22:13 -0700
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.919.2)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m3LClOPl070702 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Apr 2008 05:47:24 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m3LClORX070701; Mon, 21 Apr 2008 05:47:24 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from lochnagar.oryx.com ([195.30.37.40]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m3LClMLo070689 for <[e-mail]>; Mon, 21 Apr 2008 05:47:22 -0700 (MST) (envelope-from [e-mail])
Received: by lochnagar.oryx.com (Postfix, from userid 1000) id 8504A600049; Mon, 21 Apr 2008 14:46:47 +0200 (CEST)
Date: Mon, 21 Apr 2008 14:46:47 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: [e-mail]
Subject: Re: MIME loops: Extracting attachment to disk and replacing it with an URL
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
X-Message-Flag: WARNING! Message was not sent using Microsoft software!
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alexey Melnikov <[e-mail]>
> Elaborate on how this can be done with Sieve variables, or elaborate on
> extracting attachements in general?

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

Arnt



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m3L92QK5049566 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Apr 2008 02:02:26 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m3L92Q52049565; Mon, 21 Apr 2008 02:02:26 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m3L92PmQ049558 for <[e-mail]>; Mon, 21 Apr 2008 02:02:25 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <SAxYHwA4EZ1=@rufus.isode.com>; Mon, 21 Apr 2008 10:02:24 +0100
Message-ID: <[e-mail]>
Date: Sun, 20 Apr 2008 22:42:39 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Kjetil Torgrim Homme <[e-mail]>
CC: Barry Leiba <[e-mail]>, [e-mail]
Subject: Re: Comments on draft-ietf-sieve-notify-mailto-07.txt
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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 <[e-mail]>; Wed, 7 Dec 2005 05:08:02 -0500
>>      Received: from hobbies.example.com by mail.example.com
>>        for <[e-mail]>; Wed, 7 Dec 2005 02:00:26 -0800
>>      Date: Wed, 7 Dec 2005 05:08:55 -0500
>>      Message-ID: <[e-mail]>
>>      Auto-Submitted: sieve-notify; owner-email="[e-mail]"
>>      From: [e-mail]
>>      To: [e-mail]
>>      To: [e-mail]
>>      Subject: From Knitting list: A new sweater
>>    
>>
>
>note, multiple To-headers is not allowed by 2822.
>  
>
Fine :-). Make it:

      To: [e-mail], [e-mail]





Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m3KGF50l067187 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 20 Apr 2008 09:15:05 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m3KGF5p0067186; Sun, 20 Apr 2008 09:15:05 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m3KGF4Nv067180 for <[e-mail]>; Sun, 20 Apr 2008 09:15:05 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Sun, 20 Apr 2008 17:15:03 +0100
Message-ID: <[e-mail]>
Date: Sun, 20 Apr 2008 17:14:53 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Arnt Gulbrandsen <[e-mail]>
CC: [e-mail]
Subject: Re: MIME loops: Extracting attachment to disk and replacing it with an URL
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Arnt Gulbrandsen wrote:

> Alexey Melnikov writes:
>
>> 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.
>
> Could you elaborate?

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

>> 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.

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.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m3K9ber3022610 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 20 Apr 2008 02:37:40 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m3K9beZD022609; Sun, 20 Apr 2008 02:37:40 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m3K9bdKC022601 for <[e-mail]>; Sun, 20 Apr 2008 02:37:40 -0700 (MST) (envelope-from [e-mail])
Received: from kalyani.oryx.com (localhost.oryx.com [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id ED52D4AC85; Sun, 20 Apr 2008 11:37:38 +0200 (CEST)
Received: from 195.30.37.40 (HELO lochnagar.oryx.com) by kalyani.oryx.com with esmtp id 1208684258-48160-5830; Sun, 20 Apr 2008 11:37:38 +0200
Message-Id: <[e-mail]>
Date: Sun, 20 Apr 2008 11:37:06 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: MIME loops: Extracting attachment to disk and replacing it with an URL
Cc: Alexey Melnikov <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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
> exact URL format is known in advance.

Could you elaborate?

> So, do people think that a variant of the replace action is=20
> 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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m3K9XCfB022192 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 20 Apr 2008 02:33:12 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m3K9XCj2022190; Sun, 20 Apr 2008 02:33:12 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m3K9X4tN022170 for <[e-mail]>; Sun, 20 Apr 2008 02:33:10 -0700 (MST) (envelope-from [e-mail])
Received: from kalyani.oryx.com (localhost.oryx.com [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id C80C54AC84; Sun, 20 Apr 2008 11:33:00 +0200 (CEST)
Received: from 195.30.37.40 (HELO lochnagar.oryx.com) by kalyani.oryx.com with esmtp id 1208683980-48160-5828; Sun, 20 Apr 2008 11:33:00 +0200
Message-Id: <[e-mail]>
Date: Sun, 20 Apr 2008 11:32:27 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: Comments on draft-ietf-sieve-notify-mailto-07.txt
Cc: Alexey Melnikov <[e-mail]>, Barry Leiba <[e-mail]>, Kjetil Torgrim Homme <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m3K03nof037263 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 19 Apr 2008 17:03:49 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m3K03nNK037262; Sat, 19 Apr 2008 17:03:49 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (pat.uio.no [129.240.10.15]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m3K03kKJ037255 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Sat, 19 Apr 2008 17:03:48 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx4.uio.no ([129.240.10.45]) by pat.uio.no with esmtp (Exim 4.67) (envelope-from <[e-mail]>) id 1JnN20-0007XP-SP; Sun, 20 Apr 2008 02:03:44 +0200
Received: from smtp.uio.no ([129.240.10.9] helo=mail-mx4.uio.no) by mail-mx4.uio.no with esmtp (Exim 4.67) (envelope-from <[e-mail]>) id 1JnN20-0001AM-MD; Sun, 20 Apr 2008 02:03:44 +0200
Received: from cm-84.215.68.73.getinternet.no ([84.215.68.73]) by mail-mx4.uio.no with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from <[e-mail]>) id 1JnN20-0001AI-Jk; Sun, 20 Apr 2008 02:03:44 +0200
Subject: Re: Comments on draft-ietf-sieve-notify-mailto-07.txt
From: Kjetil Torgrim Homme <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: Barry Leiba <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>  <[e-mail]>
Content-Type: text/plain
Date: Sun, 20 Apr 2008 02:03:43 +0200
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.12.1 
Content-Transfer-Encoding: 7bit
X-UiO-SPF-Received: 
X-UiO-Resend: resent
X-UiO-SPF-Received: 
X-UiO-Spam-info: not spam, SpamAssassin (score=0.0, required=5.0, autolearn=disabled, none)
X-UiO-Scanned: 2C31AFED33A3A31F55FA5457F3DE30E4DCF24E8B
X-UiO-SR-test: 2046A6DDECDDFC473EEA6A3BF11540807B0D3F1D
X-UiO-SPAM-Test: remote_host: 129.240.10.9 spam_score: 0 maxlevel 200 minaction 2 bait 0 mail/h: 8 total 7975107 max/h 8345 blacklist 0 greylist 0 ratelimit 0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

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

-- 
Kjetil T.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m3JIhA1P015941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 19 Apr 2008 11:43:10 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m3JIhAo6015940; Sat, 19 Apr 2008 11:43:10 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from shell.mv.net (osmium.mv.net [199.125.85.152]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m3JIh9ZO015930 for <[e-mail]>; Sat, 19 Apr 2008 11:43:09 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 33180 invoked by uid 101); 19 Apr 2008 14:43:08 -0400
From: "Mark E. Mallett" <[e-mail]>
Date: Sat, 19 Apr 2008 14:43:08 -0400
To: [e-mail]
Subject: Re: editheader interaction with mailto notifications
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.2.1i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m3JIIMcq013526 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 19 Apr 2008 11:18:23 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m3JIIMCl013518; Sat, 19 Apr 2008 11:18:22 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from shell.mv.net (osmium.mv.net [199.125.85.152]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m3JIIIn9013467 for <[e-mail]>; Sat, 19 Apr 2008 11:18:21 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 4435 invoked by uid 101); 19 Apr 2008 14:18:17 -0400
From: "Mark E. Mallett" <[e-mail]>
Date: Sat, 19 Apr 2008 14:18:17 -0400
To: [e-mail]
Subject: Re: [Fwd: Re: [secdir] secdir review of draft-ietf-sieve-notify-mailto-07.txt]
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.2.1i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

[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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m3ILoAeU025690 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Apr 2008 14:50:10 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m3ILoADw025689; Fri, 18 Apr 2008 14:50:10 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m3ILo88a025677 for <[e-mail]>; Fri, 18 Apr 2008 14:50:09 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.2.141] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Fri, 18 Apr 2008 22:50:07 +0100
Message-ID: <[e-mail]>
Date: Fri, 18 Apr 2008 22:49:22 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Barry Leiba <[e-mail]>
CC: [e-mail]
Subject: Re: Comments on draft-ietf-sieve-notify-mailto-07.txt
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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 [e-mail]):

      require ["notify", "variables"];

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


   Notification message:

      Received: from mail.example.com by mail.example.org
        for <[e-mail]>; Wed, 7 Dec 2005 05:08:02 -0500
      Received: from hobbies.example.com by mail.example.com
        for <[e-mail]>; Wed, 7 Dec 2005 02:00:26 -0800
      Date: Wed, 7 Dec 2005 05:08:55 -0500
      Message-ID: <[e-mail]>
      Auto-Submitted: sieve-notify; owner-email="[e-mail]"
      From: [e-mail]
      To: [e-mail]
      To: [e-mail]
      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.......




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m3IL4TVd022051 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Apr 2008 14:04:29 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m3IL4TmJ022049; Fri, 18 Apr 2008 14:04:29 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.152]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m3IL4R1X022041 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Fri, 18 Apr 2008 14:04:28 -0700 (MST) (envelope-from [e-mail])
Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e34.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id m3IL2Bgp018217 for <[e-mail]>; Fri, 18 Apr 2008 17:02:11 -0400
Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id m3IL4QLX185762 for <[e-mail]>; Fri, 18 Apr 2008 15:04:27 -0600
Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m3IL4Qtb021497 for <[e-mail]>; Fri, 18 Apr 2008 15:04:26 -0600
Received: from poplar (poplar.watson.ibm.com [9.2.24.140]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m3IL4Qn2021482; Fri, 18 Apr 2008 15:04:26 -0600
Received: from Uranus-009002042023.watson.ibm.com ([9.2.42.23]) by poplar.watson.ibm.com (IMF.2005.07.16.1050.haw) with SMTP ID IMFd1208552665.694; Fri, 18 Apr 2008 17:04:25 -0400
Message-ID: <[e-mail]>
Date: Fri, 18 Apr 2008 17:04:26 -0400
From: Barry Leiba <[e-mail]>
User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Comments on draft-ietf-sieve-notify-mailto-07.txt
References: <[e-mail]>            <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m3IKXYDZ019384 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Apr 2008 13:33:34 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m3IKXYRm019383; Fri, 18 Apr 2008 13:33:34 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.149]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m3IKXXba019375 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Fri, 18 Apr 2008 13:33:34 -0700 (MST) (envelope-from [e-mail])
Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e31.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id m3IKXWpA028177 for <[e-mail]>; Fri, 18 Apr 2008 16:33:32 -0400
Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id m3IKXWa2076446 for <[e-mail]>; Fri, 18 Apr 2008 14:33:32 -0600
Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m3IKXWEf030065 for <[e-mail]>; Fri, 18 Apr 2008 14:33:32 -0600
Received: from poplar (poplar.watson.ibm.com [9.2.24.140]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m3IKXVOX029836; Fri, 18 Apr 2008 14:33:31 -0600
Received: from Uranus-009002042023.watson.ibm.com ([9.2.42.23]) by poplar.watson.ibm.com (IMF.2005.07.16.1050.haw) with SMTP ID IMFd1208550808.678; Fri, 18 Apr 2008 16:33:28 -0400
Message-ID: <[e-mail]>
Date: Fri, 18 Apr 2008 16:33:29 -0400
From: Barry Leiba <[e-mail]>
User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213)
MIME-Version: 1.0
To: Ned Freed <[e-mail]>
CC: Mark E Mallett <[e-mail]>, [e-mail]
Subject: Re: editheader interaction with mailto notifications
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m3IE4xPI081927 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Apr 2008 07:04:59 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m3IE4xcK081925; Fri, 18 Apr 2008 07:04:59 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m3IE4pPh081910 for <[e-mail]>; Fri, 18 Apr 2008 07:04:58 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Fri, 18 Apr 2008 15:04:51 +0100
Message-ID: <[e-mail]>
Date: Fri, 18 Apr 2008 15:04:32 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: [e-mail]
Subject: MIME loops: Extracting attachment to disk and replacing it with an URL
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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?



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m3DK3h6q012628 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 13 Apr 2008 13:03:43 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m3DK3haQ012627; Sun, 13 Apr 2008 13:03:43 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m3DK3fIb012620 for <[e-mail]>; Sun, 13 Apr 2008 13:03:42 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Sun, 13 Apr 2008 21:03:40 +0100
Message-ID: <[e-mail]>
Date: Sun, 13 Apr 2008 15:54:31 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: "Mark E. Mallett" <[e-mail]>
CC: [e-mail]
Subject: Re: [Fwd: Re: [secdir] secdir review of draft-ietf-sieve-notify-mailto-07.txt]
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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.
>  
>




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m3CI601k005738 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 12 Apr 2008 11:06:00 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m3CI60t8005737; Sat, 12 Apr 2008 11:06:00 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from shell.mv.net (osmium.mv.net [199.125.85.152]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m3CI5w14005729 for <[e-mail]>; Sat, 12 Apr 2008 11:05:59 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 88217 invoked by uid 101); 12 Apr 2008 14:05:58 -0400
From: "Mark E. Mallett" <[e-mail]>
Date: Sat, 12 Apr 2008 14:05:58 -0400
To: [e-mail]
Subject: Re: [Fwd: Re: [secdir] secdir review of draft-ietf-sieve-notify-mailto-07.txt]
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.2.1i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m3BAMjZp068316 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Apr 2008 03:22:45 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m3BAMjw5068315; Fri, 11 Apr 2008 03:22:45 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mout5.freenet.de (mout5.freenet.de [IPv6:2001:748:100:40::2:7]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m3BAMh1I068309 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Fri, 11 Apr 2008 03:22:44 -0700 (MST) (envelope-from [e-mail])
Received: from [195.4.92.11] (helo=1.mx.freenet.de) by mout5.freenet.de with esmtpa (Exim 4.69) (envelope-from <[e-mail]>) id 1JkGP3-0000k2-TK for [e-mail]; Fri, 11 Apr 2008 12:22:41 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]:58506) by 1.mx.freenet.de with esmtps (TLSv1:AES256-SHA:256) (port 25) (Exim 4.69 #12) id 1JkGP3-0001lT-Rj for [e-mail]; Fri, 11 Apr 2008 12:22:41 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.69 #18) id 1JkGP3-000656-Ey for [e-mail]; Fri, 11 Apr 2008 12:22:41 +0200
Date: Fri, 11 Apr 2008 12:22:41 +0200
To: [e-mail]
Subject: Re: [Fwd: Re: [secdir] secdir review of draft-ietf-sieve-notify-mailto-07.txt]
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
User-Agent: Heirloom mailx 12.1 6/15/06
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
From: Michael Haardt <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m3AF86SY086249 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Apr 2008 08:08:06 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m3AF868L086247; Thu, 10 Apr 2008 08:08:06 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (dsl-66-59-230-40.static.linkline.com [66.59.230.40]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m3AF82YB086238 for <[e-mail]>; Thu, 10 Apr 2008 08:08:02 -0700 (MST) (envelope-from [e-mail])
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Thu, 10 Apr 2008 08:08:00 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Thu, 10 Apr 2008 08:07:57 -0700 (PDT)
Cc: [e-mail]
Message-id: <[e-mail]>
Date: Thu, 10 Apr 2008 07:56:13 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: editheader interaction with mailto notifications
In-reply-to: "Your message dated Sun, 06 Apr 2008 16:09:58 -0400" <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
To: Mark E Mallett <[e-mail]>
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1207840079; h=Date:	 From:Subject:MIME-version:Content-type; b=ZEGl30UlrLVU+brr/TEplYHh+ fCy1AxHnT/RfPfQtVqm0iJpiXs5+Wy99P2NGwMQHlfZE541yoSKcV5Ko3ANvg==
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m39D5iKY054583 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Apr 2008 06:05:44 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m39D5iwq054582; Wed, 9 Apr 2008 06:05:44 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m39D5gd5054571 for <[e-mail]>; Wed, 9 Apr 2008 06:05:43 -0700 (MST) (envelope-from [e-mail])
Received: from kalyani.oryx.com (localhost.oryx.com [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id B770C4AC22; Wed,  9 Apr 2008 15:05:41 +0200 (CEST)
Received: from 195.30.37.40 (HELO lochnagar.oryx.com) by kalyani.oryx.com with esmtp id 1207746341-48160-1014; Wed, 9 Apr 2008 15:05:41 +0200
Message-Id: <[e-mail]>
Date: Wed, 9 Apr 2008 15:04:53 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: ManageSieve: allowed characters in script names
Cc: Alexey Melnikov <[e-mail]>, Jeffrey Hutzelman <[e-mail]>, Kjetil Torgrim Homme <[e-mail]>
References: <[e-mail]> <[e-mail]> <1207744115.14914.45.camel@oslhomkje>
In-Reply-To: <1207744115.14914.45.camel@oslhomkje>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=utf-8; format=flowed
Mime-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Kjetil Torgrim Homme writes:
> On Tue, 2008-04-08 at 11:17 -0400, Jeffrey Hutzelman wrote:
>>  Alexey Melnikov <[e-mail]> 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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m39CSjcY051203 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Apr 2008 05:28:45 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m39CSjH9051202; Wed, 9 Apr 2008 05:28:45 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (pat.uio.no [129.240.10.15]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m39CSf1b051191 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 9 Apr 2008 05:28:43 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx4.uio.no ([129.240.10.45]) by pat.uio.no with esmtp (Exim 4.67) (envelope-from <[e-mail]>) id 1JjZPp-0004l7-M3; Wed, 09 Apr 2008 14:28:37 +0200
Received: from smtp.uio.no ([129.240.10.9] helo=mail-mx4.uio.no) by mail-mx4.uio.no with esmtp (Exim 4.67) (envelope-from <[e-mail]>) id 1JjZPp-0003UG-Fq; Wed, 09 Apr 2008 14:28:37 +0200
Received: from pat-gw.osl.fast.no ([217.144.235.5] helo=[192.168.2.4]) by mail-mx4.uio.no with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from <[e-mail]>) id 1JjZPp-0003Tu-Bj; Wed, 09 Apr 2008 14:28:37 +0200
Subject: Re: ManageSieve: allowed characters in script names
From: Kjetil Torgrim Homme <[e-mail]>
To: Jeffrey Hutzelman <[e-mail]>
Cc: Alexey Melnikov <[e-mail]>, MTA filtering mailing list <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=utf-8
Date: Wed, 09 Apr 2008 14:28:35 +0200
Message-Id: <1207744115.14914.45.camel@oslhomkje>
Mime-Version: 1.0
X-Mailer: Evolution 2.12.1 
Content-Transfer-Encoding: quoted-printable
X-UiO-SPF-Received: 
X-UiO-Resend: resent
X-UiO-SPF-Received: 
X-UiO-Spam-info: not spam, SpamAssassin (score=2.5, required=5.0, autolearn=disabled, MIME_QP_LONG_LINE=2.499)
X-UiO-Spam-Score: ss
X-UiO-Scanned: EAE3A449F75979B6FFB30B7CB1339D1C232C5665
X-UiO-SR-test: 3DC1D362999F6E6DE45192FB45C6D7DD8B804454
X-UiO-Ratelimit-Test: Ratelimit
X-UiO-SPAM-Test: UIO-RATELIMIT remote_host: 129.240.10.9 spam_score: 25 maxlevel 200 minaction 2 bait 0 mail/h: 1084 total 7790892 max/h 8345 blacklist 0 greylist 0 ratelimit 1
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Tue, 2008-04-08 at 11:17 -0400, Jeffrey Hutzelman wrote:
> Alexey Melnikov <[e-mail]> 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.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m38FHY1g040683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Apr 2008 08:17:34 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m38FHYPw040682; Tue, 8 Apr 2008 08:17:34 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m38FHWK3040672 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Tue, 8 Apr 2008 08:17:33 -0700 (MST) (envelope-from [e-mail])
Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id m38FHUsb012348 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Apr 2008 11:17:30 -0400 (EDT)
Date: Tue, 08 Apr 2008 11:17:30 -0400
From: Jeffrey Hutzelman <[e-mail]>
To: Alexey Melnikov <[e-mail]>, MTA filtering mailing list <[e-mail]>
cc: [e-mail]
Subject: Re: ManageSieve: allowed characters in script names
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On Tuesday, April 08, 2008 04:00:41 PM +0100 Alexey Melnikov=20
<[e-mail]> 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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m38F0vQq039167 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Apr 2008 08:00:57 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m38F0vd7039166; Tue, 8 Apr 2008 08:00:57 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m38F0u4P039158 for <[e-mail]>; Tue, 8 Apr 2008 08:00:57 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <R=[e-mail]>; Tue, 8 Apr 2008 16:00:56 +0100
Message-ID: <[e-mail]>
Date: Tue, 08 Apr 2008 16:00:41 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: MTA filtering mailing list <[e-mail]>
Subject: ManageSieve: allowed characters in script names
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: quoted-printable
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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?



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m38BHRPD018366 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Apr 2008 04:17:27 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m38BHRXX018365; Tue, 8 Apr 2008 04:17:27 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m38BHPti018357 for <[e-mail]>; Tue, 8 Apr 2008 04:17:26 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <R=[e-mail]>; Tue, 8 Apr 2008 12:17:24 +0100
Message-ID: <[e-mail]>
Date: Tue, 08 Apr 2008 09:44:51 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= <[e-mail]>
CC: IETF Sieve WG <[e-mail]>
Subject: Re: refuse-reject SMTP multi-lines replies
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-transfer-encoding: quoted-printable
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

=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.





Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m37AC1I8001417 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Apr 2008 03:12:01 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m37AC1eP001416; Mon, 7 Apr 2008 03:12:01 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m37ABoRW001405 for <[e-mail]>; Mon, 7 Apr 2008 03:11:58 -0700 (MST) (envelope-from [e-mail])
Received: from kalyani.oryx.com (localhost.oryx.com [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id 61DDD4AC98; Mon,  7 Apr 2008 12:11:42 +0200 (CEST)
Received: from 195.30.37.40 (HELO lochnagar.oryx.com) by kalyani.oryx.com with esmtp id 1207563102-35544-248; Mon, 7 Apr 2008 12:11:42 +0200
Message-Id: <[e-mail]>
Date: Mon, 7 Apr 2008 12:10:56 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: editheader interaction with mailto notifications
Cc: "Mark E. Mallett" <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
Mime-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m36KA0Rd033285 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 6 Apr 2008 13:10:00 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m36KA0Hf033284; Sun, 6 Apr 2008 13:10:00 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from shell.mv.net (osmium.mv.net [199.125.85.152]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m36K9xdf033278 for <[e-mail]>; Sun, 6 Apr 2008 13:09:59 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 93461 invoked by uid 101); 6 Apr 2008 16:09:58 -0400
From: "Mark E. Mallett" <[e-mail]>
Date: Sun, 6 Apr 2008 16:09:58 -0400
To: [e-mail]
Subject: Re: editheader interaction with mailto notifications
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.2.1i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m36JpmkZ031643 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 6 Apr 2008 12:51:48 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m36JpmET031642; Sun, 6 Apr 2008 12:51:48 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from shell.mv.net (osmium.mv.net [199.125.85.152]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id m36JplG2031636 for <[e-mail]>; Sun, 6 Apr 2008 12:51:48 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 64484 invoked by uid 101); 6 Apr 2008 15:51:46 -0400
From: "Mark E. Mallett" <[e-mail]>
Date: Sun, 6 Apr 2008 15:51:46 -0400
To: [e-mail]
Subject: Re: [Fwd: Re: [secdir] secdir review of draft-ietf-sieve-notify-mailto-07.txt]
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.2.1i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m36JJACc029713 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 6 Apr 2008 12:19:10 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m36JJAqj029712; Sun, 6 Apr 2008 12:19:10 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.aegee.uni-karlsruhe.de (smtp.aegee.uni-karlsruhe.de [129.13.60.220]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m36JJ8Rw029705 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Sun, 6 Apr 2008 12:19:09 -0700 (MST) (envelope-from [e-mail])
Received: from smtp.aegee.org (aegeeserv.aegee.uni-karlsruhe.de [129.13.131.80]) by smtp1.rz.uni-karlsruhe.de with esmtp (Exim 4.63 #1) id 1JiaOR-0007ls-0N; Sun, 06 Apr 2008 21:19:07 +0200
X-Mail-Sent-By-AEGEE.org-Account: didopalauzov
Received: from [192.168.1.20] (d83-181-76-24.cust.tele2.de [83.181.76.24]) (authenticated bits=0) by smtp.aegee.org (8.14.2/8.13.6) with ESMTP id m36JJ5mF008787 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Sun, 6 Apr 2008 19:19:07 GMT
Message-ID: <[e-mail]>
Date: Sun, 06 Apr 2008 21:19:27 +0200
From: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= <[e-mail]>
User-Agent: Thunderbird 2.0.0.12 (Windows/20080213)
MIME-Version: 1.0
To: IETF Sieve WG <[e-mail]>
Subject: refuse-reject SMTP multi-lines replies
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: ClamAV 0.92.1/6635/Sun Apr  6 16:29:31 2008 on AEGEEserv.aegee.uni-karlsruhe.de
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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.

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m35Jk0eJ028144 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 5 Apr 2008 12:46:00 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m35Jk0nT028143; Sat, 5 Apr 2008 12:46:00 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m35Jjxc9028134 for <[e-mail]>; Sat, 5 Apr 2008 12:46:00 -0700 (MST) (envelope-from [e-mail])
Received: from kalyani.oryx.com (localhost.oryx.com [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id 101B54AC94; Sat,  5 Apr 2008 21:45:58 +0200 (CEST)
Received: from 195.30.37.40 (HELO lochnagar.oryx.com) by kalyani.oryx.com with esmtp id 1207424757-23079-1; Sat, 5 Apr 2008 21:45:57 +0200
Message-Id: <[e-mail]>
Date: Sat, 5 Apr 2008 21:45:14 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: editheader interaction with mailto notifications
Cc: Alexey Melnikov <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
Mime-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m35ABShq084532 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 5 Apr 2008 03:11:28 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m35ABSch084531; Sat, 5 Apr 2008 03:11:28 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m35ABQCM084524 for <[e-mail]>; Sat, 5 Apr 2008 03:11:27 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <R=[e-mail]>; Sat, 5 Apr 2008 11:11:25 +0100
Message-ID: <[e-mail]>
Date: Sat, 05 Apr 2008 11:11:07 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Arnt Gulbrandsen <[e-mail]>
CC: [e-mail]
Subject: Re: editheader interaction with mailto notifications
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m34JXe7K033576 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Apr 2008 12:33:40 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m34JXeFC033575; Fri, 4 Apr 2008 12:33:40 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m34JXcZe033568 for <[e-mail]>; Fri, 4 Apr 2008 12:33:39 -0700 (MST) (envelope-from [e-mail])
Received: from kalyani.oryx.com (localhost.oryx.com [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id 2357A4AC85; Fri,  4 Apr 2008 21:33:36 +0200 (CEST)
Received: from 195.30.37.40 (HELO lochnagar.oryx.com) by kalyani.oryx.com with esmtp id 1207337615-44344-2061; Fri, 4 Apr 2008 21:33:35 +0200
Message-Id: <[e-mail]>
Date: Fri, 4 Apr 2008 21:32:53 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: editheader interaction with mailto notifications
Cc: Alexey Melnikov <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
Mime-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m34IkZOD030382 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Apr 2008 11:46:36 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m34IkZ4h030381; Fri, 4 Apr 2008 11:46:35 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mauve.mrochek.com (dsl-66-59-230-40.static.linkline.com [66.59.230.40]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m34IkYbL030375 for <[e-mail]>; Fri, 4 Apr 2008 11:46:35 -0700 (MST) (envelope-from [e-mail])
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]> for [e-mail]; Fri, 4 Apr 2008 11:46:33 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <[e-mail]>; Fri, 04 Apr 2008 11:46:30 -0700 (PDT)
Cc: MTA filtering mailing list <[e-mail]>
Message-id: <[e-mail]>
Date: Fri, 04 Apr 2008 11:46:17 -0700 (PDT)
From: Ned Freed <[e-mail]>
Subject: Re: editheader interaction with mailto notifications
In-reply-to: "Your message dated Thu, 03 Apr 2008 19:45:03 +0100" <[e-mail]>
References: <[e-mail]>
To: Alexey Melnikov <[e-mail]>
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1207334792; h=Date:	 From:Subject:MIME-version:Content-type; b=YPP0T/8CIhCNFtPN0VD4uj2+8 iaZiTh4mmOSPPge25cGA+nsbHTUpcoeW+IXfuMbeTy3XNUUTJsa2WJKyt9YYg==
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m33JovT3020649 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Apr 2008 12:50:57 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m33JovuA020648; Thu, 3 Apr 2008 12:50:57 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m33Jot4C020642 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Thu, 3 Apr 2008 12:50:56 -0700 (MST) (envelope-from [e-mail])
Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id m33Jon7K028424 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Apr 2008 15:50:49 -0400 (EDT)
Date: Thu, 03 Apr 2008 15:50:49 -0400
From: Jeffrey Hutzelman <[e-mail]>
To: Barry Leiba <[e-mail]>, Alexey Melnikov <[e-mail]>
cc: [e-mail], [e-mail]
Subject: Re: Comments on draft-ietf-sieve-notify-mailto-07.txt
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>            <UxwmaK04/[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--On Thursday, April 03, 2008 09:16:58 AM -0400 Barry Leiba 
<[e-mail]> 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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m33Ijp2B015644 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Apr 2008 11:45:51 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m33Ijp2V015643; Thu, 3 Apr 2008 11:45:51 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m33Ijnwg015636 for <[e-mail]>; Thu, 3 Apr 2008 11:45:50 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <R=[e-mail]>; Thu, 3 Apr 2008 19:45:48 +0100
Message-ID: <[e-mail]>
Date: Thu, 03 Apr 2008 19:45:03 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: MTA filtering mailing list <[e-mail]>
Subject: editheader interaction with mailto notifications
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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?



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m33Hhkw6012112 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Apr 2008 10:43:46 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m33HhkR4012111; Thu, 3 Apr 2008 10:43:46 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m33HhiC8012104 for <[e-mail]>; Thu, 3 Apr 2008 10:43:45 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <R=[e-mail]>; Thu, 3 Apr 2008 18:43:44 +0100
Message-ID: <[e-mail]>
Date: Thu, 03 Apr 2008 18:43:06 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: SIEVE <[e-mail]>
Subject: Re: Charter update
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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"'



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m33GMqtA005107 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Apr 2008 09:22:57 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m33GMqX3005106; Thu, 3 Apr 2008 09:22:52 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m33GMoDI005097 for <[e-mail]>; Thu, 3 Apr 2008 09:22:51 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <R=[e-mail]>; Thu, 3 Apr 2008 17:22:50 +0100
Message-ID: <[e-mail]>
Date: Thu, 03 Apr 2008 17:22:17 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Michael Haardt <[e-mail]>
CC: [e-mail]
Subject: Re: Comments on draft-ietf-sieve-notify-mailto-07.txt
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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:[e-mail]?to=[e-mail]", then the 
>>envelope recipient is [e-mail] and not 
>>[e-mail].
>>
>>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:[e-mail][e-mail]>
>
>   is equivalent to
>
>   <mailto:?to=[e-mail][e-mail]>
>
>   is equivalent to
>
>   <mailto:[e-mail]?to=[e-mail]>
>
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.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m33E1GhG093736 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Apr 2008 07:01:16 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m33E1GkI093735; Thu, 3 Apr 2008 07:01:16 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m33E1F73093728 for <[e-mail]>; Thu, 3 Apr 2008 07:01:16 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <R=[e-mail]>; Thu, 3 Apr 2008 15:01:15 +0100
Message-ID: <[e-mail]>
Date: Thu, 03 Apr 2008 15:00:50 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Barry Leiba <[e-mail]>
CC: [e-mail]
Subject: Re: Comments on draft-ietf-sieve-notify-mailto-07.txt
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

(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.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m33DssGG093199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Apr 2008 06:54:54 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m33DssHq093198; Thu, 3 Apr 2008 06:54:54 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mout5.freenet.de (mout5.freenet.de [IPv6:2001:748:100:40::2:7]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m33DsqAj093190 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 3 Apr 2008 06:54:53 -0700 (MST) (envelope-from [e-mail])
Received: from [195.4.92.22] (helo=12.mx.freenet.de) by mout5.freenet.de with esmtpa (Exim 4.69) (envelope-from <[e-mail]>) id 1JhPtz-00033r-3D for [e-mail]; Thu, 03 Apr 2008 15:54:51 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]:48217) by 12.mx.freenet.de with esmtps (TLSv1:AES256-SHA:256) (port 25) (Exim 4.69 #12) id 1JhPtz-0002yM-2a for [e-mail]; Thu, 03 Apr 2008 15:54:51 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.69 #18) id 1JhPty-0004yY-IR for [e-mail]; Thu, 03 Apr 2008 15:54:50 +0200
Date: Thu, 03 Apr 2008 15:54:50 +0200
To: [e-mail]
Subject: Re: Comments on draft-ietf-sieve-notify-mailto-07.txt
References: <[e-mail]> <UxwmaK04/[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
User-Agent: Heirloom mailx 12.1 6/15/06
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
From: Michael Haardt <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m33Daw8x091465 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Apr 2008 06:36:58 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m33Dawxi091463; Thu, 3 Apr 2008 06:36:58 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m33DatEg091401 for <[e-mail]>; Thu, 3 Apr 2008 06:36:57 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <R=[e-mail]>; Thu, 3 Apr 2008 14:36:54 +0100
Message-ID: <[e-mail]>
Date: Thu, 03 Apr 2008 14:36:31 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Barry Leiba <[e-mail]>
CC: [e-mail]
Subject: Re: Comments on draft-ietf-sieve-notify-mailto-07.txt
References: <[e-mail]> <UxwmaK04/[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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 ;-).



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m33DKt5J089672 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Apr 2008 06:20:55 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m33DKt19089671; Thu, 3 Apr 2008 06:20:55 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.152]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m33DKr35089654 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Thu, 3 Apr 2008 06:20:54 -0700 (MST) (envelope-from [e-mail])
Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e34.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id m33DJAhn026252 for <[e-mail]>; Thu, 3 Apr 2008 09:19:10 -0400
Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id m33DKrUl198374 for <[e-mail]>; Thu, 3 Apr 2008 07:20:53 -0600
Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m33DKq6x012518 for <[e-mail]>; Thu, 3 Apr 2008 07:20:52 -0600
Received: from poplar (poplar.watson.ibm.com [9.2.24.140]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m33DKq6D012485; Thu, 3 Apr 2008 07:20:52 -0600
Received: from Uranus-009002042023.watson.ibm.com ([9.2.42.23]) by poplar.watson.ibm.com (IMF.2005.07.16.1050.haw) with SMTP ID IMFd1207228852.8437; Thu, 03 Apr 2008 08:20:52 -0400
Date: Thu, 03 Apr 2008 09:20:51 -0400
From: Barry Leiba <[e-mail]>
To: Alexey Melnikov <[e-mail]>
cc: [e-mail]
Subject: Re: Comments on draft-ietf-sieve-notify-mailto-07.txt
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m33DH3Jv089372 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Apr 2008 06:17:03 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m33DH3gY089371; Thu, 3 Apr 2008 06:17:03 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.153]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m33DH1Me089364 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Thu, 3 Apr 2008 06:17:02 -0700 (MST) (envelope-from [e-mail])
Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e35.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id m33DH00s018783 for <[e-mail]>; Thu, 3 Apr 2008 09:17:00 -0400
Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id m33DH0wH158992 for <[e-mail]>; Thu, 3 Apr 2008 07:17:00 -0600
Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m33DH0SV032699 for <[e-mail]>; Thu, 3 Apr 2008 07:17:00 -0600
Received: from poplar (poplar.watson.ibm.com [9.2.24.140]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m33DGxnj032679; Thu, 3 Apr 2008 07:17:00 -0600
Received: from Uranus-009002042023.watson.ibm.com ([9.2.42.23]) by poplar.watson.ibm.com (IMF.2005.07.16.1050.haw) with SMTP ID IMFd1207228619.8434; Thu, 03 Apr 2008 08:16:59 -0400
Date: Thu, 03 Apr 2008 09:16:58 -0400
From: Barry Leiba <[e-mail]>
To: Alexey Melnikov <[e-mail]>
cc: [e-mail]
Subject: Re: Comments on draft-ietf-sieve-notify-mailto-07.txt
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>            <UxwmaK04/[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m33CpuD6086852 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Apr 2008 05:51:56 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m33CpuEa086851; Thu, 3 Apr 2008 05:51:56 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m33CpsbT086841 for <[e-mail]>; Thu, 3 Apr 2008 05:51:55 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <R=[e-mail]>; Thu, 3 Apr 2008 13:51:54 +0100
Message-ID: <[e-mail]>
Date: Thu, 03 Apr 2008 13:51:33 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Arnt Gulbrandsen <[e-mail]>
CC: [e-mail], Barry Leiba <[e-mail]>
Subject: Re: Comments on draft-ietf-sieve-notify-mailto-07.txt
References: <[e-mail]> <UxwmaK04/[e-mail]>
In-Reply-To: <UxwmaK04/[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m33CfBwl085954 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Apr 2008 05:41:11 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m33CfBLT085953; Thu, 3 Apr 2008 05:41:11 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mout5.freenet.de (mout5.freenet.de [IPv6:2001:748:100:40::2:7]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m33Cf9vo085947 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 3 Apr 2008 05:41:10 -0700 (MST) (envelope-from [e-mail])
Received: from [195.4.92.11] (helo=1.mx.freenet.de) by mout5.freenet.de with esmtpa (Exim 4.69) (envelope-from <[e-mail]>) id 1JhOkd-0008Ky-H5 for [e-mail]; Thu, 03 Apr 2008 14:41:07 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]:59981) by 1.mx.freenet.de with esmtps (TLSv1:AES256-SHA:256) (port 25) (Exim 4.69 #12) id 1JhOkd-0002E4-FJ for [e-mail]; Thu, 03 Apr 2008 14:41:07 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.69 #18) id 1JhOkc-0004uV-Jm for [e-mail]; Thu, 03 Apr 2008 14:41:06 +0200
Date: Thu, 03 Apr 2008 14:41:06 +0200
To: [e-mail]
Subject: Re: Comments on draft-ietf-sieve-notify-mailto-07.txt
References: <[e-mail]>
In-Reply-To: <[e-mail]>
User-Agent: Heirloom mailx 12.1 6/15/06
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
From: Michael Haardt <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 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:[e-mail]?to=[e-mail]", then the 
> envelope recipient is [e-mail] and not 
> [e-mail].
>
> 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:[e-mail][e-mail]>

   is equivalent to

   <mailto:?to=[e-mail][e-mail]>

   is equivalent to

   <mailto:[e-mail]?to=[e-mail]>

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m33C1flh082367 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Apr 2008 05:01:41 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m33C1fSf082366; Thu, 3 Apr 2008 05:01:41 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m33C1eqB082358 for <[e-mail]>; Thu, 3 Apr 2008 05:01:40 -0700 (MST) (envelope-from [e-mail])
Received: from kalyani.oryx.com (localhost.oryx.com [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id 290984AC23; Thu,  3 Apr 2008 14:01:39 +0200 (CEST)
Received: from 195.30.37.40 (HELO lochnagar.oryx.com) by kalyani.oryx.com with esmtp id 1207224099-44344-1214; Thu, 3 Apr 2008 14:01:39 +0200
Message-Id: <UxwmaK04/[e-mail]>
Date: Thu, 3 Apr 2008 14:00:54 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: Comments on draft-ietf-sieve-notify-mailto-07.txt
Cc: Alexey Melnikov <[e-mail]>, Barry Leiba <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
Mime-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m33Bg7ju080035 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Apr 2008 04:42:08 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m33Bg7lQ080034; Thu, 3 Apr 2008 04:42:07 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m33Bg64d080026 for <[e-mail]>; Thu, 3 Apr 2008 04:42:07 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <R=[e-mail]>; Thu, 3 Apr 2008 12:42:03 +0100
Message-ID: <[e-mail]>
Date: Thu, 03 Apr 2008 11:19:41 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Barry Leiba <[e-mail]>
CC: [e-mail]
Subject: Comments on draft-ietf-sieve-notify-mailto-07.txt
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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:[e-mail]?to=[e-mail]", then the 
envelope recipient is [e-mail] and not 
[e-mail].

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?

**



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m32KgktR009115 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Apr 2008 13:42:46 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m32KgkJM009114; Wed, 2 Apr 2008 13:42:46 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mout0.freenet.de (mout0.freenet.de [IPv6:2001:748:100:40::2:2]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m32Kgf0B009092 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 2 Apr 2008 13:42:45 -0700 (MST) (envelope-from [e-mail])
Received: from [195.4.92.17] (helo=7.mx.freenet.de) by mout0.freenet.de with esmtpa (Exim 4.69) (envelope-from <[e-mail]>) id 1Jh9n2-0001SQ-8u for [e-mail]; Wed, 02 Apr 2008 22:42:36 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]:48155) by 7.mx.freenet.de with esmtps (TLSv1:AES256-SHA:256) (port 25) (Exim 4.69 #12) id 1Jh9n2-0006PC-7r for [e-mail]; Wed, 02 Apr 2008 22:42:36 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.69 #17) id 1Jh9n1-0004XG-90 for [e-mail]; Wed, 02 Apr 2008 22:42:35 +0200
Date: Wed, 02 Apr 2008 22:42:35 +0200
To: [e-mail]
Subject: Re: [Fwd: Re: [secdir] secdir review of draft-ietf-sieve-notify-mailto-07.txt]
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
User-Agent: Heirloom mailx 12.1 6/15/06
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
From: Michael Haardt <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> >"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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m32KSTIS008020 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Apr 2008 13:28:29 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m32KSTI0008019; Wed, 2 Apr 2008 13:28:29 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m32KSSpR008013 for <[e-mail]>; Wed, 2 Apr 2008 13:28:29 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <R=[e-mail]>; Wed, 2 Apr 2008 21:28:28 +0100
Message-ID: <[e-mail]>
Date: Wed, 02 Apr 2008 21:27:47 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Arnt Gulbrandsen <[e-mail]>
CC: [e-mail]
Subject: Re: [Fwd: Re: [secdir] secdir review of draft-ietf-sieve-notify-mailto-07.txt]
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <A2rX/[e-mail]>
In-Reply-To: <A2rX/[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m32KQ0H4007865 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Apr 2008 13:26:00 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m32KQ0mt007864; Wed, 2 Apr 2008 13:26:00 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m32KPxd6007857 for <[e-mail]>; Wed, 2 Apr 2008 13:26:00 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <R=[e-mail]>; Wed, 2 Apr 2008 21:25:58 +0100
Message-ID: <[e-mail]>
Date: Wed, 02 Apr 2008 21:25:17 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Barry Leiba <[e-mail]>
CC: [e-mail]
Subject: Re: secdir review of draft-ietf-sieve-notify-mailto-07.txt
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m32DlCMm067234 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Apr 2008 06:47:12 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m32DlC3H067233; Wed, 2 Apr 2008 06:47:12 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from pat.uio.no (pat.uio.no [129.240.10.15]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m32DlA08067223 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 2 Apr 2008 06:47:11 -0700 (MST) (envelope-from [e-mail])
Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 4.67) (envelope-from <[e-mail]>) id 1Jh3Iz-0000Ka-Bq; Wed, 02 Apr 2008 15:47:09 +0200
Received: from smtp.uio.no ([129.240.10.9] helo=mail-mx3.uio.no) by mail-mx3.uio.no with esmtp (Exim 4.67) (envelope-from <[e-mail]>) id 1Jh3Iz-0003Ma-03; Wed, 02 Apr 2008 15:47:09 +0200
Received: from pat-gw.osl.fast.no ([217.144.235.5] helo=[192.168.2.4]) by mail-mx3.uio.no with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from <[e-mail]>) id 1Jh3Iy-0003MN-RR; Wed, 02 Apr 2008 15:47:08 +0200
Subject: Re: [Fwd: Re: [secdir] secdir review of draft-ietf-sieve-notify-mailto-07.txt]
From: Kjetil Torgrim Homme <[e-mail]>
To: Alexey Melnikov <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain
Date: Wed, 02 Apr 2008 15:47:07 +0200
Message-Id: <1207144027.8453.17.camel@oslhomkje>
Mime-Version: 1.0
X-Mailer: Evolution 2.12.1 
Content-Transfer-Encoding: 7bit
X-UiO-SPF-Received: 
X-UiO-Resend: resent
X-UiO-SPF-Received: 
X-UiO-Spam-info: not spam, SpamAssassin (score=0.0, required=5.0, autolearn=disabled, none)
X-UiO-Scanned: 3A2800C05396EA77CE139D3C75E0849B0FC092DF
X-UiO-SR-test: ABCE5EF1BB9ECDFFDAF97AC897603EC829EE9E0B
X-UiO-Ratelimit-Test: Ratelimit
X-UiO-SPAM-Test: UIO-RATELIMIT remote_host: 129.240.10.9 spam_score: 0 maxlevel 200 minaction 2 bait 0 mail/h: 1558 total 7664882 max/h 8345 blacklist 0 greylist 0 ratelimit 1
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m32DaBRT066111 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Apr 2008 06:36:11 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m32DaBho066109; Wed, 2 Apr 2008 06:36:11 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.151]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m32DaAZf066101 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Wed, 2 Apr 2008 06:36:10 -0700 (MST) (envelope-from [e-mail])
Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e33.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id m32Da9oa023449 for <[e-mail]>; Wed, 2 Apr 2008 09:36:09 -0400
Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id m32Da9RE098150 for <[e-mail]>; Wed, 2 Apr 2008 07:36:09 -0600
Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m32Da9NB021095 for <[e-mail]>; Wed, 2 Apr 2008 07:36:09 -0600
Received: from poplar (poplar.watson.ibm.com [9.2.24.140]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m32Da8jq021056 for <[e-mail]>; Wed, 2 Apr 2008 07:36:08 -0600
Received: from Uranus-009002042023.watson.ibm.com ([9.2.42.23]) by poplar.watson.ibm.com (IMF.2005.07.16.1050.haw) with SMTP ID IMFd1207143368.8144; Wed, 02 Apr 2008 08:36:08 -0400
Message-ID: <[e-mail]>
Date: Wed, 02 Apr 2008 09:36:08 -0400
From: Barry Leiba <[e-mail]>
User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213)
MIME-Version: 1.0
To: SIEVE <[e-mail]>
Subject: OT: Conference on Email and Anti-Spam final call for papers
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: quoted-printable
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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
    [e-mail]


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/
----------------------------------------------------------------------




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m32C5jLk055858 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Apr 2008 05:05:45 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m32C5iN8055849; Wed, 2 Apr 2008 05:05:44 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m32C5Zbn055604 for <[e-mail]>; Wed, 2 Apr 2008 05:05:44 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <R=[e-mail]>; Wed, 2 Apr 2008 13:05:34 +0100
Message-ID: <[e-mail]>
Date: Wed, 02 Apr 2008 13:05:17 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Michael Haardt <[e-mail]>
CC: [e-mail]
Subject: Re: [Fwd: Re: [secdir] secdir review of draft-ietf-sieve-notify-mailto-07.txt]
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m328GUT2026998 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Apr 2008 01:16:30 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m328GU0H026997; Wed, 2 Apr 2008 01:16:30 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m328GSRQ026991 for <[e-mail]>; Wed, 2 Apr 2008 01:16:29 -0700 (MST) (envelope-from [e-mail])
Received: from kalyani.oryx.com (localhost.oryx.com [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id 029A44AC83; Wed,  2 Apr 2008 10:16:28 +0200 (CEST)
Received: from 195.30.37.40 (HELO lochnagar.oryx.com) by kalyani.oryx.com with esmtp id 1207124187-44344-470; Wed, 2 Apr 2008 10:16:27 +0200
Message-Id: <A2rX/[e-mail]>
Date: Wed, 2 Apr 2008 10:15:42 +0200
From: Arnt Gulbrandsen <[e-mail]>
To: [e-mail]
Subject: Re: [Fwd: Re: [secdir] secdir review of draft-ietf-sieve-notify-mailto-07.txt]
Cc: Alexey Melnikov <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; format=flowed
Mime-Version: 1.0
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m328FkZr026938 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Apr 2008 01:15:46 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m328FkBk026937; Wed, 2 Apr 2008 01:15:46 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mout2.freenet.de (mout2.freenet.de [IPv6:2001:748:100:40::2:4]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m328Fhgr026930 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 2 Apr 2008 01:15:45 -0700 (MST) (envelope-from [e-mail])
Received: from [195.4.92.15] (helo=5.mx.freenet.de) by mout2.freenet.de with esmtpa (Exim 4.69) (envelope-from <[e-mail]>) id 1Jgy8D-00070W-NC for [e-mail]; Wed, 02 Apr 2008 10:15:41 +0200
Received: from nostromo.freenet-ag.de ([194.97.7.6]:43479) by 5.mx.freenet.de with esmtps (TLSv1:AES256-SHA:256) (port 25) (Exim 4.69 #12) id 1Jgy8D-0005A1-Mr for [e-mail]; Wed, 02 Apr 2008 10:15:41 +0200
Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.69 #17) id 1Jgy8D-0004Fj-9z for [e-mail]; Wed, 02 Apr 2008 10:15:41 +0200
Date: Wed, 02 Apr 2008 10:15:41 +0200
To: [e-mail]
Subject: Re: [Fwd: Re: [secdir] secdir review of draft-ietf-sieve-notify-mailto-07.txt]
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
User-Agent: Heirloom mailx 12.1 6/15/06
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
From: Michael Haardt <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> >>>      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



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m31JK7Yp068473 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Apr 2008 12:20:07 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m31JK7Nf068471; Tue, 1 Apr 2008 12:20:07 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m31JK6I0068461 for <[e-mail]>; Tue, 1 Apr 2008 12:20:07 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <R=[e-mail]>; Tue, 1 Apr 2008 20:20:05 +0100
Message-ID: <[e-mail]>
Date: Tue, 01 Apr 2008 20:19:23 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Arnt Gulbrandsen <[e-mail]>
CC: [e-mail]
Subject: Re: [Fwd: Re: [secdir] secdir review of draft-ietf-sieve-notify-mailto-07.txt]
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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?



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m31BW5gS003804 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Apr 2008 04:32:05 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m31BW5ZU003803; Tue, 1 Apr 2008 04:32:05 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m31BW1x5003794 for <[e-mail]>; Tue, 1 Apr 2008 04:32:04 -0700 (MST) (envelope-from [e-mail])
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <R=[e-mail]>; Tue, 1 Apr 2008 12:32:00 +0100
Message-ID: <[e-mail]>
Date: Mon, 31 Mar 2008 23:41:29 +0100
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Patrick Ben Koetter <[e-mail]>
CC: [e-mail]
Subject: Re: Standard to selectively disable rules in sieve script?
References: <[e-mail]> <[e-mail]> <1206575521.16281.72.camel@oslhomkje> <00c001c88fa7$1e8e1ec0$6401a8c0@nigelhome> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Patrick,

Patrick Ben Koetter wrote:

>* Nigel Swinson <[e-mail]>:
>  
>
>>>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.