Subject: Please review ; Sieve Statistics and Sieve remove attachments

From: Madan Ganesh Velayudham <[email-masked]>
Date: Fri, 30 Jan 2004 01:20:18 +0530

Hello,
	
	Please share views on the following :

"SIEVE Statistics", Madan Velayudham, 03-Dec-03. (9179 bytes)

http://www.ietf.org/internet-drafts/draft-madanganeshv-sieve-stat-00.txt

This draft describes a mechanism of collecting the statistical 
information about sieve action on the received mail. It introduces 
GETSTAT and RESETSTAT commands to [MSIEVE] to get and reset the 
statistic information about the sieve actions.

"SIEVE: Remove attachment(s)", Madan Velayudham, 23-Dec-03. (8185 bytes) "

http://ietf.org/internet-drafts/draft-madanganeshv-sieve-remove-attach-00.txt 

This draft introduces an action command 'fileinto-except' to [SIEVE] in 
order to move a message to a folder without certain attachments of the 
received message.

	Thanks and Regards,
	MG

-- 
  _____________________________________________________________
      ___
     /___\      Madan ganesh Velayudham
    |/. .\|     STSD, India
    (   ) )     +91 80 (2) 205 3108
     \ = /
     _)_(_   There are no limitation in what you can do
             except the limitations of your own mind.
_____________________________________________________________

---

From: Lyndon Nerenberg <[email-masked]>
Date: Thu, 29 Jan 2004 13:09:46 -0800

> "SIEVE Statistics", Madan Velayudham, 03-Dec-03. (9179 bytes)

Some comments based on a quick scan of the document ...

Section 4:

* "action" needs to be more clearly defined

Section 5:

* Why two capabilities? Both commands are required, so there's 	no 
point in advertising two capability strings. The capability should be 
changed to something like "STATISTICS".

Section 6:

* What does a "zero valued action counter" mean? Surely '0' is a valid 
counter value, meaning the action has never been triggered. I think 
what you're implying here is that a '0' value means the counter for the 
action isn't implemented. If that's the case, just don't return a 
response for that action.

* Presumably GETSTAT is only valid in authenticated state? (Section 7 
explicitly calls this out, so section 6 should as well.)

Section 8:

* The grammar (and semantic description) for the command responses is 
missing.

Section 9:

* Since there's no way (that I can see) to access another users counter 
data (through the protocol), this text doesn't seem relevant.

General:

* How useful is the returned data? The fact that an action took place 
doesn't really tell me anything. I would be much more interested in 
seeing how often each rule fired, as that would allow me to optimize my 
rulesets.

--lyndon

Date: Thu, 29 Jan 2004 13:09:46 -0800
From: Lyndon Nerenberg <[email-masked]>
To: Madan Ganesh Velayudham <[email-masked]>, [email-masked]
Subject: Re: Please review ; Sieve Statistics and Sieve remove attachments
Sender: [email-masked]

> "SIEVE Statistics", Madan Velayudham, 03-Dec-03. (9179 bytes)

Some comments based on a quick scan of the document ...

Section 4:

* "action" needs to be more clearly defined

Section 5:

* Why two capabilities? Both commands are required, so there's 	no 
point in advertising two capability strings. The capability should be 
changed to something like "STATISTICS".

Section 6:

* What does a "zero valued action counter" mean? Surely '0' is a valid 
counter value, meaning the action has never been triggered. I think 
what you're implying here is that a '0' value means the counter for the 
action isn't implemented. If that's the case, just don't return a 
response for that action.

* Presumably GETSTAT is only valid in authenticated state? (Section 7 
explicitly calls this out, so section 6 should as well.)

Section 8:

* The grammar (and semantic description) for the command responses is 
missing.

Section 9:

* Since there's no way (that I can see) to access another users counter 
data (through the protocol), this text doesn't seem relevant.

General:

* How useful is the returned data? The fact that an action took place 
doesn't really tell me anything. I would be much more interested in 
seeing how often each rule fired, as that would allow me to optimize my 
rulesets.

--lyndon

Date: Fri, 30 Jan 2004 01:20:18 +0530
From: Madan Ganesh Velayudham <[email-masked]>
To: [email-masked]
Subject: Please review ; Sieve Statistics and Sieve remove attachments
Sender: [email-masked]

Hello,

	Thanks and Regards,
	MG

Date: Wed, 28 Jan 2004 13:01:36 -0500
From: Ken Murchison <[email-masked]>
Reply-To: Cyrus Mailing List <[email-masked]>
Organization: Oceana Matrix Ltd.
To: [email-masked]
CC: [email-masked], Cyrus Mailing List <[email-masked]>
Subject: Re: Sieve Extensions
Sender: [email-masked]

[email-masked] wrote:

> hi,
> 
> Is besides the basic sieve action extensions (fileinto, keep, redirect,
> reject, discard & vacation) the regex or subadresses extensions currently
> implemented?, so that I can used it in an script run on an cyrus imapd 2.2.17.

I'm moving this message to the info-cyrus list where its more appropriate.

The answer to your question is yes, the Cyrus Sieve implementation 
supports both of these extensions

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

Date: Wed, 28 Jan 2004 01:48:09 +0100 (MET)
From: [email-masked]
To: [email-masked]
Subject: Sieve Extensions
Sender: [email-masked]

hi,

Is besides the basic sieve action extensions (fileinto, keep, redirect,
reject, discard & vacation) the regex or subadresses extensions currently
implemented?, so that I can used it in an script run on an cyrus imapd 2.2.17.

best regards
-john gildman

-- 
+++ GMX - die erste Adresse für Mail, Message, More +++
Bis 31.1.: TopMail + Digicam für nur 29 EUR http://www.gmx.net/topmail

Date: Sun, 25 Jan 2004 08:17:22 -0800 (PST)
From: [email-masked]
Subject: AD review comments on draft-showalter-sieve-vacation-05.txt
To: [email-masked]
Cc: [email-masked], [email-masked]
Sender: [email-masked]

(Unfortunately this draft has expired. Hopefully this can be corrected in a
timely fashion.)

I reviewed this document once in the past and most of the issues I had were
addressed at that time. The only ones I see that remain are:

(1) In section 3.5 it should be noted that in-reply-to need not be generated
    if the original message doesn't have a message-id. A references field
    should also be generated and set similarly.

(2) In section 3.6 Resent- field variants should be checked for addresses in
    addition to the To:/Cc:/Bcc: fields.

(3) A new section needs to be added before section 3.6 that discusses how
    to set the From: field in vacaation responses. I believe the correct
    advice to give is that the field SHOULD be set to the address of the
    sieve owner.

(4) A new section needs to be added before section 3.6 that discusses how to
    set the To: field in vacation responses. It should say that the
    To: field SHOULD be set to the address of the recipient of the
    response.

(5) A new section needs to be added that says an Auto-submitted: field
    with a value of "auto-replied" SHOULD be included in the message header
    of any vacation reply that is sent.

(6) The sections describing the response message to send are mingled
    with the sections describing the various vacation action parameters.
    These really need to be teased out into a separate major section. The
    major section should also say that the generated response must be
    a valid email message with all of the required header fields present.

(7) This document needs to be reconciled with Keith Moore's draft on
    auto-responders, draft-moore-auto-email-response-04.txt, which has been
    through last call. I've thought about this a lot, and I think the right
    way to do it is to simply add a section that discusses what sort of
    auto-responder this is in Keith's terms. Something like this:

4. Relationship to "Recommendations for Automatic Responses to Electronic Mail"

  The sieve vacation extension implements a "Personal Responder" in the
  terminology defined in [AUTO]. Care has been taken in this specification
  to comply with the recommendations [AUTO] makes in regards to how
  personal responders should behave.

  And of course a reference to [AUTO] needs to be added to the references
  section:

  [AUTO] Moore, K., "Recommendations for Automatic Responses to Electronic
  Mail", Internet-Draft, draft-moore-auto-email-response-04.txt.

(8) The security consideration section is likely to be seen as inadequate
    in its discussion of potential problems auto-responders can cause.
    Fortunately there's a nice way to resolve this without adding a bunch
    of text to the present document: Refer to Keith Moore's auto-responder
    draft with a sentence like:

  Security issues associated with mail auto-responders are fully discussed
  in the security consideration section of [AUTO].

(9) An IANA considerations section needs to be added just after the security
    considerations:

5 IANA Considerations
    
    The following template specifies the IANA registration of the vacation Sieve
    extension specified in this document:
    
    To: [email-masked]
    Subject: Registration of new Sieve extension

    Capability name: vacation
    Capability keyword: vacation
    Capability arguments: N/A
    Standards Track/IESG-approved experimental RFC number: this RFC
    Person and email address to contact for further information:

     Tim Showalter
     Mirapoint, Inc.
     909 Hermosa Court
     Sunnyvale, CA 94085

     E-Mail: [email-masked]

    This information should be added to the list of sieve extensions
    given on http://www.iana.org/assignments/sieve-extensions.

(10) The references section needs to be split into normative and informative
     groups. I believe [MAILBOXNAMES] belongs in the informative section 
     while all the others, including [AUTO], belong in the normative
     section.

(11) IPR boilerplate needs to be added just before the copyright:

Appendix B Intellectual Property Rights Statement

    The IETF takes no position regarding the validity or scope of any
    intellectual property or other rights that might be claimed to
    pertain to the implementation or use of the technology described in
    this document or the extent to which any license under such rights
    might or might not be available; neither does it represent that it
    has made any effort to identify any such rights.  Information on the
    IETF's procedures with respect to rights in standards-track and
    standards-related documentation can be found in BCP-11.  Copies of
    claims of rights made available for publication and any assurances
    of licenses to be made available, or the result of an attempt made
    to obtain a general license or permission for the use of such
    proprietary rights by implementors or users of this specification
    can be obtained from the IETF Secretariat.

That's it.

				Ned

Date: Sun, 25 Jan 2004 08:12:10 -0800 (PST)
From: [email-masked]
Subject: Re: AD review comments on draft-degener-sieve-copy-01.txt
To: [email-masked]
Cc: Jutta Degener <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

> I just reviewed this specification and I think it is quite close to being ready
> for last call. My only comments are:

Oops, missed one. The title of Appendix A needs to be changed to
"Appendix A. Normative references". Sorry about that.

				Ned

Date: Sun, 25 Jan 2004 07:47:32 -0800 (PST)
From: [email-masked]
Subject: AD review comments on draft-degener-sieve-copy-01.txt
To: Jutta Degener <[email-masked]>
Cc: [email-masked], [email-masked]
Sender: [email-masked]

I just reviewed this specification and I think it is quite close to being ready
for last call. My only comments are:

(1) An example showing the use of  the extentsion is needed. In particular,
    I've found that it really helps to have something that shows people what
    needs to be in the "reauire" clause.

(2) There needs to be an IANA considerations section telling IANA what
    to do. Something like this should appear as a section after the security
    considerations:

5 IANA Considerations
    
    The following template specifies the IANA registration of the copy Sieve
    extension specified in this document:
    
    To: [email-masked]
    Subject: Registration of new Sieve extension

    Capability name: copy
    Capability keyword: copy
    Capability arguments: N/A
    Standards Track/IESG-approved experimental RFC number: this RFC
    Person and email address to contact for further information:

      Jutta Degener
      Sendmail, Inc.
      6425 Christie Ave, 4th Floor
      Emeryville, CA 94608

      Email: [email-masked]

    This information should be added to the list of sieve extensions
    given on http://www.iana.org/assignments/sieve-extensions.
    
(3) IPR boilerplate is missing and needs to be added as a separate section
    just before the copyright:
    
Appendix B Intellectual Property Rights Statement

    The IETF takes no position regarding the validity or scope of any
    intellectual property or other rights that might be claimed to
    pertain to the implementation or use of the technology described in
    this document or the extent to which any license under such rights
    might or might not be available; neither does it represent that it
    has made any effort to identify any such rights.  Information on the
    IETF's procedures with respect to rights in standards-track and
    standards-related documentation can be found in BCP-11.  Copies of
    claims of rights made available for publication and any assurances
    of licenses to be made available, or the result of an attempt made
    to obtain a general license or permission for the use of such
    proprietary rights by implementors or users of this specification
    can be obtained from the IETF Secretariat.

That's it. Jutta, if you can make these changes quickly that would be great, if
not I'll probably go ahead and get the last call started anyway and the update
can happen during the last call.

				Ned

From: "Mark E. Mallett" <[email-masked]>
Date: Wed, 21 Jan 2004 10:53:59 -0500
To: Nigel Swinson <[email-masked]>
Cc: Jutta Degener <[email-masked]>, [email-masked]
Subject: Re: draft-degener-sieve-editheader-01.txt; "refuse" action
Sender: [email-masked]

On Wed, Jan 21, 2004 at 12:27:45AM -0000, Nigel Swinson wrote:
>  
> > Should we say that
> > [ ] the first fileinto wins, say that
> > [ ] any one fileinto may win (but it has to be one of
> >     the actual fileintos - can't have just half the
> >     headers or additional headers),
> > [ ] the last fileinto wins,
> > [ ] or leave it completely open?
> > 
> > I'd like one of the first three -- I think if it is one of the
> > fourth, it starts weakening the connection between message modification
> > and message use, and I'd like that connection to be a strong one.
> 
> Well action-as-you-go implementations are going to vote for 1,
> actions-all-at-the-end impelmentations are going to vote for 3, and I
> think we need to make it equally feasable to implement either way
> which means I think we have to have either option 2 or 4.  So that
> makes me vote for option 2?

That seems logical.

mm

From: "Nigel Swinson" <[email-masked]>
To: "Jutta Degener" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: draft-degener-sieve-editheader-01.txt; "refuse" action
Date: Wed, 21 Jan 2004 00:27:45 -0000
Sender: [email-masked]

> > >   A message modified by addheader or deleteheader MUST NOT
> > >   be considered the same as the original message unless it
> > >   matches the original message exactly.
> 
> At this point, I'd like to throw this out as well.  Anyone have
> a compelling reason not to?
>
> Personally, I'd like it to be replaced by an explicit statement
> saying that these added headers do *not* make the message different.

Great!  I'd like it thrown too, but it does sounds a little bizzare to do put in the counter statement, as we all know that it isn't actually the same message.   If we are throwing it out, doesn't it make any of the following 4 options correct?
 
> Should we say that
> [ ] the first fileinto wins, say that
> [ ] any one fileinto may win (but it has to be one of
>     the actual fileintos - can't have just half the
>     headers or additional headers),
> [ ] the last fileinto wins,
> [ ] or leave it completely open?
> 
> I'd like one of the first three -- I think if it is one of the
> fourth, it starts weakening the connection between message modification
> and message use, and I'd like that connection to be a strong one.

Well action-as-you-go implementations are going to vote for 1, actions-all-at-the-end impelmentations are going to vote for 3, and I think we need to make it equally feasable to implement either way which means I think we have to have either option 2 or 4.  So that makes me vote for option 2?

Nigel

Date: Tue, 20 Jan 2004 13:53:28 -0800
From: Jutta Degener <[email-masked]>
To: "Matthew Elvey (FM)" <[email-masked]>
Cc: [email-masked]
Subject: Re: draft-degener-sieve-editheader-01.txt; "refuse" action
Sender: [email-masked]

On Tue, Jan 20, 2004 at 11:49:11AM -0800, Matthew Elvey (FM) wrote:
> I'd like to see this go away:
> 
> >   A message modified by addheader or deleteheader MUST NOT
> >   be considered the same as the original message unless it
> >   matches the original message exactly.

At this point, I'd like to throw this out as well.  Anyone have
a compelling reason not to?

Personally, I'd like it to be replaced by an explicit statement
saying that these added headers do *not* make the message different.

Should we say that
[ ] the first fileinto wins, say that
[ ] any one fileinto may win (but it has to be one of
    the actual fileintos - can't have just half the
    headers or additional headers),
[ ] the last fileinto wins,
[ ] or leave it completely open?

I'd like one of the first three -- I think if it is one of the
fourth, it starts weakening the connection between message modification
and message use, and I'd like that connection to be a strong one.

> I'd like to see replaceheader reconsidered for the spec, or at least any 
> objections to it made public; the standards-setting process must be public.

As I remember it, Ned Freed was vocal and clear on the list about his
intention to do everything in his powers to stop replaceheader, to
general mumbling approval.  Maybe I misinterpreted something?

Jutta

Date: Tue, 20 Jan 2004 15:31:38 -0500
From: Cyrus Daboo <[email-masked]>
To: "Matthew Elvey (FM)" <[email-masked]>, [email-masked]
Subject: Re: draft-degener-sieve-editheader-01.txt; "refuse" action
Sender: [email-masked]

Hi Cyrus,

--On Tuesday, January 20, 2004 15:10 -0500 Cyrus Daboo <[email-masked]> 
wrote:

| but I think its reasonable that append is the default.

I meant to say that I think it is reasonable that append (:last) is 
available as an option - I don't want to argue that it should be the 
default.

I personally would likely always use :last as I frequently have to examine 
the chain of Received headers for debugging purposes and having other 
headers interspersed would be annoying. Right now the CMU sieve 
implementation does add an X-CMU-Sieve header and that does appear before 
the final delivery Received header as their SIEVE implementation sits 
between SMTP and LMPT.

-- 
Cyrus Daboo

Date: Tue, 20 Jan 2004 15:10:59 -0500
From: Cyrus Daboo <[email-masked]>
To: "Matthew Elvey (FM)" <[email-masked]>, [email-masked]
Subject: Re: draft-degener-sieve-editheader-01.txt; "refuse" action
Sender: [email-masked]

Hi Matthew,

--On Tuesday, January 20, 2004 11:49 -0800 "Matthew Elvey (FM)" 
<[email-masked]> wrote:

| Let's keep it simple.  Wow, I'm not aware there's good precedent for MUAs
| appending instead of prepending.  I thought they prepended, like good
| MTAs do. I'd like to see addheader put the added header at the top, where
| new headers are *supposed* to go (or so I thought), anyone have a
| compelling real case where :last is needed?

Most of the mailing list software I have come across appends List- headers 
rather than prepends them. Same thing for anti-spam/anti-virus warnings 
etc. One can argue whether those types of tools are MUAs or MTAs by some 
definition, but I think its reasonable that append is the default.

-- 
Cyrus Daboo

Date: Tue, 20 Jan 2004 11:59:30 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: ADMINISTRIVIA: Hopefully no more Windows viruses
Sender: [email-masked]

Greetings again. I have just installed a procmail filter on this list 
that should prevent Windows viruses from getting to the mailing list. 
It won't prevent them all, so you need to continue to remember not to 
execute stuff that you receive from this (or any!) mailing list.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Tue, 20 Jan 2004 11:49:11 -0800
From: "Matthew Elvey (FM)" <[email-masked]>
To: [email-masked]
Subject: Re: draft-degener-sieve-editheader-01.txt; "refuse" action
Sender: [email-masked]

My belated two cents - just that; I don't feel strongly; no responses 
necessary.

Let's keep it simple.  Wow, I'm not aware there's good precedent for 
MUAs appending instead of prepending.  I thought they prepended, like 
good MTAs do. I'd like to see addheader put the added header at the top, 
where new headers are *supposed* to go (or so I thought), anyone have a 
compelling real case where :last is needed?

I'd like to see this go away:

>    A message modified by addheader or deleteheader MUST NOT
>    be considered the same as the original message unless it
>    matches the original message exactly.

I'd like to see replaceheader reconsidered for the spec, or at least any 
objections to it made public; the standards-setting process must be public.

This does apply the KISS principle because it'll mean an otherwise 
imminent vendor-specific implementation will be unnecessary.
******
FYI: Progress is being made on the draft for the "refuse" action; Alexey 
and I should post a draft soon; we've worked through a bunch of issues 
already.

Date: Tue, 20 Jan 2004 15:13:19 +0530
To: [email-masked]
Subject: Hi
From: [email-masked]
Sender: [email-masked]

----------403654051214462
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

 Test =)
ptexgfqjwdms
--
Test, yep.

----------403654051214462
Content-Type: application/x-msdownload; name="fys.exe"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="kjw.exe"

----------403654051214462--

Date: Mon, 19 Jan 2004 15:14:30 +0900
To: [email-masked]
Subject: Hi
From: [email-masked]
Sender: [email-masked]

----------357723350507838
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

 Test =)
qsynlkea
--
Test, yep.

----------357723350507838
Content-Type: application/x-msdownload; name="taxkrybrqch.exe"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="cqwhdhaamhi.exe"

----------357723350507838--

From: "Mark E. Mallett" <[email-masked]>
Date: Fri, 16 Jan 2004 01:46:09 -0500
To: Philip Guenther <[email-masked]>
Cc: "Mark E. Mallett" <[email-masked]>, [email-masked]
Subject: Re: draft-degener-sieve-editheader-01.txt
Sender: [email-masked]

On Thu, Jan 15, 2004 at 08:35:51PM -0800, Philip Guenther wrote:
> "Mark E. Mallett" <[email-masked]> writes:
> ... [regarding default placement of added header fields]
> >My contention is that in a local
> >delivery mode, one ought to be able to do to the mail what one wants
> >to do to it.  As I said, I could see where there could be more
> >constraints on a filter that was operating in other than local
> >delivery mode.  However I think it would be a shame to cripple a local
> >delivery agent for that reason:  it would be better to define an
> >operational mode that had more constraints if one wanted.
> 
> Given that the draft *does* provide a means to do what you want
> (place the added header field at the end of the header instead of
> the beginning), calling an agent that follows the draft 'crippled'
> seems like pure hyperbole.

I didn't say that last phrase, so it's hard to respond to it.  An agent
that follows this draft in either of its last two forms is not
crippled.  I didn't even say (or intend to say, though I think I can
see how it got inferred) that the draft is "crippled" by the default
being the beginning rather than the end.  I was talking about the line
of reasoning leading up to this point:  i.e., that there is a
precedent set by MTAs prepending headers, and MUAs appending them.  I
said that a SIEVE filter (certainly by one definition) can commonly be
a local agent acting on behalf of the mailbox owner.  I said that I
could imagine another mode where it was acting more MTA-like, and that
perhaps a mode could be defined where the filter was not allowed such
a free hand (since it would be operating on mail *other* than that
owned by the person directing it).  (In fact I think it would be
useful to make that role distinction when talking about what a filter
can and can not do.)  I then said that that hypothetical mode should
not be the one that dictated the way drafts (or agents) were written;
if it were, it would be restrictive (i.e., crippling) for the LDA
role.  It's a few steps back from that philosophical observation to
the specific item in the draft, sorry about the apparent connection.

> Can you refute the previously provided
> reasons for defaulting to prepending or otherwise provide a
> countervailing argument?

Not "refute" -- no.  Disagree with, yes, but really only mildly, and
I've outlined why a few times.  If I wasn't clear I can try again, but
I doubt that people need to have me belabor it.  For reasons I've
already given I feel that appending is better for a final delivery
agent.  A draft stage is where one puts in these opinions so I am:
obviously other(s) felt similarly motivated, though in the other
direction, between the last two drafts.  I would even suggest having
the default be implementation-dependent, and if one wanted to be
explicit one would use :first or :last .

> ... [regarding replaceheader]
> 
> The question isn't whether replaceheader should be described in an
> rfc.  The question is whether addheader and deleteheader should be
> held up while the people try to reach consensus on replaceheader.
> It's one thing to combine separable extensions in a single document
> when they're all ready to go at the same time, but that isn't true
> here.

Yeah- that's one reason I was wondering where this discussion had
taken place up to now (between the last two drafts, that is).  If
you've been involved in discussing it you have a different perspective
than I, who only knows that it is gone and wonders why, and wonders
what will become of it.  I certainly understand the goal of pragmatism,
especially if there's conflict over "replaceheader".  But it's also
a good goal to have an extension that encapsulates all related functions.

Yours,
-mm-

To: "Mark E. Mallett" <[email-masked]>
Cc: [email-masked]
From: Philip Guenther <[email-masked]>
Subject: Re: draft-degener-sieve-editheader-01.txt 
Date: Thu, 15 Jan 2004 20:35:51 -0800
Sender: [email-masked]

"Mark E. Mallett" <[email-masked]> writes:
... [regarding default placement of added header fields]
>My contention is that in a local
>delivery mode, one ought to be able to do to the mail what one wants
>to do to it.  As I said, I could see where there could be more
>constraints on a filter that was operating in other than local
>delivery mode.  However I think it would be a shame to cripple a local
>delivery agent for that reason:  it would be better to define an
>operational mode that had more constraints if one wanted.

Given that the draft *does* provide a means to do what you want
(place the added header field at the end of the header instead of
the beginning), calling an agent that follows the draft 'crippled'
seems like pure hyperbole.  Can you refute the previously provided
reasons for defaulting to prepending or otherwise provide a
countervailing argument?

... [regarding replaceheader]
>There certainly could be situations where replaceheader can't
>do what you want: but that's no reason to remove it.

It wasn't removed because it didn't do what was wanteded; it was
removed because people felt it too complicated and had various
hairy problems (for example, involving rfc2047-encoded words).

...
>That's not really what I was getting at.  I'd want to see
>"replaceheader" retained in the draft, even if it's as a "MAY" with a
>separate capability name (a la the "envelope" precedent) rather than
>punted like that with no chance for uniform implementation of optional
>facilities.  Certainly anything can be incorporated in a private
>implementation, but that's not this discussion.

The question isn't whether replaceheader should be described in an
rfc.  The question is whether addheader and deleteheader should be
held up while the people try to reach consensus on replaceheader.
It's one thing to combine separable extensions in a single document
when they're all ready to go at the same time, but that isn't true
here.

Philip Guenther
[email-masked]

From: "Mark E. Mallett" <[email-masked]>
Date: Thu, 15 Jan 2004 21:52:44 -0500
To: Jutta Degener <[email-masked]>
Cc: [email-masked]
Subject: Re: draft-degener-sieve-editheader-01.txt
Sender: [email-masked]

On Thu, Jan 15, 2004 at 04:50:14PM -0800, Jutta Degener wrote:
> > But in the (more common) case where
> > the filter is operating on behalf of the recipient, I would want to be
> > able to do the changes I want done.  (kind of a tautology there.)
> 
> I don't think we have enough data to judge which use of
> this proposed extension is common.

I was referring to common use of sieve, per its stated design as a
final delivery agent.  However, I did allude to the possibility that a
sieve filter *could* be used in a pass-through mode, since you were
the one who was talking about MTA-like properties providing precedent
for header placement, and I was making some conjectures about where
that perspective was coming from.  My contention is that in a local
delivery mode, one ought to be able to do to the mail what one wants
to do to it.  As I said, I could see where there could be more
constraints on a filter that was operating in other than local
delivery mode.  However I think it would be a shame to cripple a local
delivery agent for that reason:  it would be better to define an
operational mode that had more constraints if one wanted.

> > > > And.. what about replaceheader?
> > > 
> > > As mentioned in section 9.1, replaceheader is no longer in the draft.
> > > My implementation still has it, but it's a vendor-specific extension
> > > after encountering determined opposition from some members of the
> > > work group.  If you implement it, the rules with respect to duplication
> > > would be the same as for add- and deleteheader.
> > 
> > Hmm- certainly seems like replaceheader is a convenient shortcut
> > for "deleteheader" and "replaceheader" -- except that you lose
> > position, which I consider a loss (for reasons given above).
> 
> You lose count, too; if multiple headers of the same sort are present,
> you can't generally rename them (e.g., Cc to Resent-Cc) because you
> can't loop in sieve.

While that is true (no loops), I'm not sure it's a real answer.  There
are ways to address that concern, a couple of which you illustrated in
a previous draft (nicely showing its usefulness).  Rename them all,
rename the nth one, rename the ones matching a pattern, per prior
draft.  There certainly could be situations where replaceheader can't
do what you want: but that's no reason to remove it.

> > How does a vendor-specific extension get specified vis-a-vis "require" ?
> 
> RFC 3028, section 6.1.  Their name starts with "vnd."

That's not really what I was getting at.  I'd want to see
"replaceheader" retained in the draft, even if it's as a "MAY" with a
separate capability name (a la the "envelope" precedent) rather than
punted like that with no chance for uniform implementation of optional
facilities.  Certainly anything can be incorporated in a private
implementation, but that's not this discussion.

> 
> > And in that light, could not the rules for duplication also become
> > "vendor-specific" ?
> 
> In general, I don't think that's a good way of dealing with conflicting
> opinions about details of an implementation.

My point too :-)

mm

Date: Thu, 15 Jan 2004 16:50:14 -0800
From: Jutta Degener <[email-masked]>
To: [email-masked]
Subject: Re: draft-degener-sieve-editheader-01.txt
Sender: [email-masked]

> But in the (more common) case where
> the filter is operating on behalf of the recipient, I would want to be
> able to do the changes I want done.  (kind of a tautology there.)

I don't think we have enough data to judge which use of
this proposed extension is common.

> > > And.. what about replaceheader?
> > 
> > As mentioned in section 9.1, replaceheader is no longer in the draft.
> > My implementation still has it, but it's a vendor-specific extension
> > after encountering determined opposition from some members of the
> > work group.  If you implement it, the rules with respect to duplication
> > would be the same as for add- and deleteheader.
> 
> Hmm- certainly seems like replaceheader is a convenient shortcut
> for "deleteheader" and "replaceheader" -- except that you lose
> position, which I consider a loss (for reasons given above).

You lose count, too; if multiple headers of the same sort are present,
you can't generally rename them (e.g., Cc to Resent-Cc) because you
can't loop in sieve.

> This response brings up a couple new questions too, which can only
> be explained by my ignorance I'm afraid, but here goes:
> 
> Is there a separate work group for "editheader"?

There's no IETF work group (anymore) for sieve -- so all extensions are
formally private submissions, although they do tend to refernce to this
mailing list as a point of discussion.

> How does a vendor-specific extension get specified vis-a-vis "require" ?

RFC 3028, section 6.1.  Their name starts with "vnd."

> And in that light, could not the rules for duplication also become
> "vendor-specific" ?

In general, I don't think that's a good way of dealing with conflicting
opinions about details of an implementation.

Jutta

From: "Mark E. Mallett" <[email-masked]>
Date: Thu, 15 Jan 2004 18:55:35 -0500
To: Jutta Degener <[email-masked]>
Cc: "Mark E. Mallett" <[email-masked]>, [email-masked]
Subject: Re: draft-degener-sieve-editheader-01.txt
Sender: [email-masked]

On Wed, Jan 07, 2004 at 04:53:37PM -0800, Jutta Degener wrote:

Hi-  thanks for the responses.  Sorry it's been over a week.

> On Wed, Jan 07, 2004 at 06:03:04PM -0500, Mark E. Mallett wrote:
> > Two very interesting changes in this draft:
> >
> > >    	"addheader" [":last"] <name: string> <value: string>
> > > 
> > >    By default, the header field is inserted at the beginning of
> > >    the existing header.  If the optional flag ":last" is
> > >    specified, it is appended at the end.
> > 
> > What's the rationale?  So far (i.e., without hearing more), I liked it
> > better the way it was: the default being to add the header at the end,
> > not the beginning.  I would not mind seeing a ":first" to alter that
> > behaviour though.
> 
> It's much easier to insert a header field at the beginning of
> a header (one simply sends that header field, then the text of
> a message).  Perhaps as a result of that, the fields at the
> beginning of the message have taken on the character of a
> delivery "trace", while the fields at the end of the block
> typically were inserted by the client.

I don't look at it that way, myself.  Not to mention that I don't
think "ease" has anything to do with it in a sieve application: that
application is manipulating the message, and so putting the header one
place is no more difficult than putting it another.  I do follow that
you are explaining why adding at the beginning is a precedent.  However
it's a precedent for a different context.

> Some people who talked to me felt very strongly that additions
> to the trace section in the right place were more in keeping with
> what's considered allowable header modifications, while inserting
> in the middle, with no way of tracking who did that, should only
> happen if explicitly requested.

I would disagree with those people :-)  We're not talking MTA here nor
are we talking about trace fields: we're talking about manipulating a
message where there is the presumption that one has the right to do
so, in the same way that one can go into a text editor and manipulate
it.  Admittedly there is a quasi- area where a sieve filter can be
applied in a forwarding context.  But in the (more common) case where
the filter is operating on behalf of the recipient, I would want to be
able to do the changes I want done.  (kind of a tautology there.)

Regarding the duplicate "keep" after a changed message:

> > I see where that is coming from.  If you do a "keep" after changing
> > the header, it's assumed that you really meant it; and if weeding out
> > duplicate "keep" operations prevents that, then you have lost some
> > change.  However: you have not lost the message unless some prior
> > action had deliberately caused it; any weeding out represents a script
> > error rather than loss of the message, so I am not sure this is an
> > improvement.
> 
> In an ambiguous and possibly erroneous situation, I prefer to err
> on the side of shorter explanations and more saved information.

I think the shortest explanation would be not to introduce the
"changed message" concept.  One might say that if one has done a "keep"
then changed the message then did a "keep" again, an error can occur no
matter how you look at it, so keeping the traditional de-duplication
logic is better.  I find this new potential for duplicate filings
disturbing.

> > One alternative: make a note that the message has changed, and if so,
> > inhibit any subsequent de-duplication logic on the next action only.
> 
> That seems difficult to explain.  I don't see why the first of
> any number of duplicate fileinto's etc. should receive preferential
> treatment.

Because of what I said in the original message:

     On the flip side, anyone who has depended on duplicate "keep"
     operations being weeded out will be surprised by having two
     messages filed.  Likely if you have done a "keep" in the same
     code area as the addheader, you probably do want the second
     copy.  But in another case?  Not so clear, especially if you have
     done something else with the message after changing the header.

I guess I wasn't clear with that.  I was trying to say that it's likely
that if you do an immediate "keep" right after the addheader, you
probably meant to keep the changed message.  But if there's a "keep"
far away further in the script, you probably want the de-duplication
to happen (i.e., supress that other far-away "keep").  I was trying to
invent some reason why you would really want the second keep to file
the message again (after a change), and contrast that with what I
consider to be the standard case where you don't want it to happen, and
then come up with a generic rule to infer intent as expressed in the
language.  Perhaps a better inference would be:  if there is a header
modification followed by an action within the same code block (block
enclosed by curly braces), ignore the de-duplication and perform the
action anyway.

The bottom line is that I don't like the part where normal de-duplication
is inhibited.  I'd vote for getting rid of the new stuff about the changed
message, and if that prevents the filing of a changed message, fix the
script :-)

> > And.. what about replaceheader?
> 
> As mentioned in section 9.1, replaceheader is no longer in the draft.
> My implementation still has it, but it's a vendor-specific extension
> after encountering determined opposition from some members of the
> work group.  If you implement it, the rules with respect to duplication
> would be the same as for add- and deleteheader.

Hmm- certainly seems like replaceheader is a convenient shortcut
for "deleteheader" and "replaceheader" -- except that you lose
position, which I consider a loss (for reasons given above).
(As I recall, earlier discussion included some finer control over
header placement; again, losing that is, it seems to me, a loss.)

This response brings up a couple new questions too, which can only
be explained by my ignorance I'm afraid, but here goes:

Is there a separate work group for "editheader"?  I had thought from
the archives that it open for discussion here.  What other work groups
are there?

How does a vendor-specific extension get specified vis-a-vis "require" ?
And in that light, could not the rules for duplication also become
"vendor-specific" ?

Yours,
mm

Date: Wed, 7 Jan 2004 20:03:23 -0800
From: Jutta Degener <[email-masked]>
To: [email-masked]
Subject: Re: draft-degener-sieve-editheader-01.txt
Sender: [email-masked]

On Thu, Jan 08, 2004 at 02:59:11AM -0000, Nigel Swinson wrote:
> So it seems that as it is written, editheader is putting strong bias on
> "take actions as you go" implementations.

What was intended was merely a strong bias for a "take
actions as you go" *model*.  I think that's easier to explain
and remember for users.

As an implementor, you can postpone header edits in the same
way you postpone other commands; you just need to keep track of
what the header looks like right now, and remember which
deliveries picked up which modifications.

Jutta

From: "Nigel Swinson" <[email-masked]>
To: "Jutta Degener" <[email-masked]>, "Mark E. Mallett" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: draft-degener-sieve-editheader-01.txt
Date: Thu, 8 Jan 2004 02:59:11 -0000
Sender: [email-masked]

> > >    A message modified by addheader or deleteheader MUST NOT
> > >    be considered the same as the original message unless it
> > >    matches the original message exactly.
> > >
> > >    For example, the following code fragment
> > >
> > >    keep;
> > > addheader "X-Flavor: vanilla"
> > > keep;
> > >
> > >    files two messages, not one.

The above represents a problem for those of us who have read section 2.10.6
of 3028 and decided to do a full execution of the script, then apply all
actions.... if we come across a script like this:

 keep;
 addheader "X-Flavor: vanilla"
 keep;
 addheader "X-Flavor: strawberry"
 keep;
 addheader "X-Flavor: chocolate"
 keep;
 addheader "X-Flavor: pistachio"
 keep;
 addheader "X-Flavor: bannana"
 keep;

And we are filtering a large message (Say 20MB), then the simple and obvious
implementation is going to have to freeze a copy of the message every time
it sees fileinto/redirect/keep and then if it sees addheader/removeheader it
will need to create a copy of the message.  This means that with the above
script we'll end up with 6 different copies of the message = 120MB of
memory/storage.  Sounds like a potential security hole.

So it seems that as it is written, editheader is putting strong bias on
"take actions as you go" implementations.  Do we want do do this?

I can't see that the above functionality is really all that useful, so at
the moment I'm inclined to say that we move more towards section "2.10.3
Message Uniqueness in a Mailbox" of 3028 which says:

   Implementations SHOULD NOT deliver a message to the same folder more
   than once, even if a script explicitly asks for a message to be
   written to a mailbox twice.

I think it makes it too complicated to consider there to be any more than
one "message" in context when processing the script.

So what should the keep/addheader/keep script do?  I recon it files one copy
of the message into the inbox, and the implementation is free to either add
the version with or without the header.  If the user really wants to keep a
copy that does NOT have the header, then they do keep/stop.  If they want
one with the header they do addheader/keep.

I know some will probably not like the above, but then 3028 already permits
implementations to operate differently WRT to some situations like catching
errors.  ie an "action-as-you-go" with a fileinto/reject/reject script may
file the message before producing an error, so I think it would be ok for
this slightly peculiar case to operate in an implementation specific way.

Nigel

Date: Wed, 7 Jan 2004 17:50:03 -0800
From: Jutta Degener <[email-masked]>
To: "Mark E. Mallett" <[email-masked]>
Cc: [email-masked]
Subject: Re: draft-degener-sieve-body-02.txt
Sender: [email-masked]

On Wed, Jan 07, 2004 at 06:56:30PM -0500, Mark E. Mallett wrote:
> 
> In the new :binary stuff:
> 
> > Unlike in :content, the charset of the :binary MIME content is
> > disregarded.   Instead, the match against the keys provided in
> > the "body" statement proceeds as if the file's content data had
> > been translated into space-separated hex bytes of the form
> > [0-9a-f][0-9a-f] prior to matching
> 
> It would be nice to consider whitespace in the pattern as
> insignificant,

At first, I figured it just would be binary strings.  But that
doesn't work with everything being UTF-8.  There are lots of 
binary strings that aren't valid UTF-8.

I then tried pretending the binary is ISO-8859-1 and encoding
it in UTF-8.  But that's really too silly to explain, there
are binary sequences that aren't valid ISO-8859-1, and most
humans are bad at doing ISO-8859-1-to-UTF-8 conversions in
their head.

Okay, so we're matching against a hexdump.  Easy.  Everybody
likes hexdumps.  But that doesn't give you a way around
nybble-shift -- matching hex f5 in "ow" (6f57).

Finally, the space-separated bytes were a way of anchoring the
nybbles and still having a readable string that can be used
with existing string match mechanisms like :contains and :matches.

If you want to send a white-space-normalizer into the world,
you could do that as a generic comparator and make a lot of sense
in a lot of different contexts.  But by completely disregarding
white space, you'd do more harm than good in the context of
matching a hexdump.

> especially since one has to transform it anyway in order
> to do the comparison.

Given the ability to match against that white space and individual
nybbles (I'm not happy about that, but restricting it added more
warts than it fixed), the transformation to binary that you may
have in mind doesn't quite work in the general case anyway.

> For another, if whitespace is allowed at all, why
> not let the script writer feel free to use it the way they
> want to..

I could do that, but then I'd have to toss use of the existing match
types and define my own just for binary.  I didn't think the extra
mechanism was worth it.

> And speaking of variables, is it reasonable to make some note about
> whether the matched strings are available to the variables extension?

Given how hard to implement that is, it probably should!
What do you think it should it say?

Jutta <[email-masked]>

Date: Wed, 7 Jan 2004 16:53:37 -0800
From: Jutta Degener <[email-masked]>
To: "Mark E. Mallett" <[email-masked]>
Cc: [email-masked]
Subject: Re: draft-degener-sieve-editheader-01.txt
Sender: [email-masked]

On Wed, Jan 07, 2004 at 06:03:04PM -0500, Mark E. Mallett wrote:
> Two very interesting changes in this draft:
>
> >    	"addheader" [":last"] <name: string> <value: string>
> > 
> >    By default, the header field is inserted at the beginning of
> >    the existing header.  If the optional flag ":last" is
> >    specified, it is appended at the end.
> 
> What's the rationale?  So far (i.e., without hearing more), I liked it
> better the way it was: the default being to add the header at the end,
> not the beginning.  I would not mind seeing a ":first" to alter that
> behaviour though.

It's much easier to insert a header field at the beginning of
a header (one simply sends that header field, then the text of
a message).  Perhaps as a result of that, the fields at the
beginning of the message have taken on the character of a
delivery "trace", while the fields at the end of the block
typically were inserted by the client.

Some people who talked to me felt very strongly that additions
to the trace section in the right place were more in keeping with
what's considered allowable header modifications, while inserting
in the middle, with no way of tracking who did that, should only
happen if explicitly requested.  As one of the people who occasionally
has to decipher the traces to figure out where some problem originates,
that made intuitive sense to me.

> and:
> 
> >    A message modified by addheader or deleteheader MUST NOT
> >    be considered the same as the original message unless it
> >    matches the original message exactly.
> >    
> >    For example, the following code fragment
> > 
> >    	keep;
> > 	addheader "X-Flavor: vanilla"
> > 	keep;
> > 
> >    files two messages, not one.
> 
> I see where that is coming from.  If you do a "keep" after changing
> the header, it's assumed that you really meant it; and if weeding out
> duplicate "keep" operations prevents that, then you have lost some
> change.  However: you have not lost the message unless some prior
> action had deliberately caused it; any weeding out represents a script
> error rather than loss of the message, so I am not sure this is an
> improvement.

In an ambiguous and possibly erroneous situation, I prefer to err
on the side of shorter explanations and more saved information.

> One alternative: make a note that the message has changed, and if so,
> inhibit any subsequent de-duplication logic on the next action only.

That seems difficult to explain.  I don't see why the first of
any number of duplicate fileinto's etc. should receive preferential
treatment.

> BTW, in the absence of a "changed" flag, this new philosophy might also
> imply that implicit keep is once again turned on (if it had been
> turned off).  Whether it is or is not is now ambiguous.

It is my intention that the implicit keep should _not_ be restored
after a header modification.  I'll weaken the section on weeding out
duplicates to (hopefully) be less likely to inspire that idea.

> And.. what about replaceheader?

As mentioned in section 9.1, replaceheader is no longer in the draft.
My implementation still has it, but it's a vendor-specific extension
after encountering determined opposition from some members of the
work group.  If you implement it, the rules with respect to duplication
would be the same as for add- and deleteheader.

Jutta <[email-masked]>

From: "Mark E. Mallett" <[email-masked]>
Date: Wed, 7 Jan 2004 18:56:30 -0500
To: [email-masked]
Subject: Re: draft-degener-sieve-body-02.txt
Sender: [email-masked]

In the new :binary stuff:

> Unlike in :content, the charset of the :binary MIME content is
> disregarded.   Instead, the match against the keys provided in
> the "body" statement proceeds as if the file's content data had
> been translated into space-separated hex bytes of the form
> [0-9a-f][0-9a-f] prior to matching

It would be nice to consider whitespace in the pattern as
insignificant, especially since one has to transform it anyway in order
to do the comparison.  For one thing, at some point variable
substitution is likely to come up (even if it isn't referred to here),
and one shouldn't have to worry about framing the binary data with
spaces properly.  For another, if whitespace is allowed at all, why
not let the script writer feel free to use it the way they
want to..

And speaking of variables, is it reasonable to make some note about
whether the matched strings are available to the variables extension?

Yours,
mm

From: "Mark E. Mallett" <[email-masked]>
Date: Wed, 7 Jan 2004 18:03:04 -0500
To: [email-masked]
Subject: Re: draft-degener-sieve-editheader-01.txt
Sender: [email-masked]

Two very interesting changes in this draft:

>    	"addheader" [":last"] <name: string> <value: string>
> 
>    By default, the header field is inserted at the beginning of
>    the existing header.  If the optional flag ":last" is
>    specified, it is appended at the end.

What's the rationale?  So far (i.e., without hearing more), I liked it
better the way it was: the default being to add the header at the end,
not the beginning.  I would not mind seeing a ":first" to alter that
behaviour though.

and:

>    A message modified by addheader or deleteheader MUST NOT
>    be considered the same as the original message unless it
>    matches the original message exactly.
>    
>    For example, the following code fragment
> 
>    	keep;
> 	addheader "X-Flavor: vanilla"
> 	keep;
> 
>    files two messages, not one.

I see where that is coming from.  If you do a "keep" after changing
the header, it's assumed that you really meant it; and if weeding out
duplicate "keep" operations prevents that, then you have lost some
change.  However: you have not lost the message unless some prior
action had deliberately caused it; any weeding out represents a script
error rather than loss of the message, so I am not sure this is an
improvement.

On the flip side, anyone who has depended on duplicate "keep"
operations being weeded out will be surprised by having two messages
filed.  Likely if you have done a "keep" in the same code area as the
addheader, you probably do want the second copy.  But in another
case?  Not so clear, especially if you have done something else with
the message after changing the header.

One alternative: make a note that the message has changed, and if so,
inhibit any subsequent de-duplication logic on the next action only.
So the next "keep" would succeed unless (e.g.) "redirect" were done
first.  This would introduce a new "changed" flag, but this new text
introduces that concept anyway.  That's not as perfect as, say, views,
but it's no worse than the suggested one.

BTW, in the absence of a "changed" flag, this new philosophy might also
imply that implicit keep is once again turned on (if it had been
turned off).  Whether it is or is not is now ambiguous.

And.. what about replaceheader?  I would assume that any change made
by replaceheader would also cause the message to be considered
"different" -- but that new text explicitly calls out "editheader" and
"deleteheader" without mentioning "replaceheader," so it seems
deliberate.

Yours,
mm