Re: draft-degener-sieve-editheader-01.txt
"Nigel Swinson" <nigel.swinson@rockliffe.com> Thu, 08 January 2004 03:21 UTC
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i083LBib098611 for <ietf-mta-filters-bks@above.proper.com>; Wed, 7 Jan 2004 19:21:11 -0800 (PST) (envelope-from owner-ietf-mta-filters@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i083LBgq098610 for ietf-mta-filters-bks; Wed, 7 Jan 2004 19:21:11 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f
Received: from starship.enterprise.ucs.ed.ac.uk (starship.enterprise.ucs.ed.ac.uk [129.215.40.70]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i083L9ib098604 for <ietf-mta-filters@imc.org>; Wed, 7 Jan 2004 19:21:10 -0800 (PST) (envelope-from nigel.swinson@rockliffe.com)
Received: from SCOTTY (unverified [129.215.188.53]) by starship.enterprise.ucs.ed.ac.uk (Rockliffe SMTPRA 5.3.3) with ESMTP id <B0000011341@starship.enterprise.ucs.ed.ac.uk>; Thu, 8 Jan 2004 02:59:11 +0000
Message-ID: <015d01c3d593$647565b0$662c2a0a@rockliffe.com>
From: Nigel Swinson <nigel.swinson@rockliffe.com>
To: Jutta Degener <jutta@sendmail.com>, "Mark E. Mallett" <mem@mv.mv.com>
Cc: ietf-mta-filters@imc.org
References: <20040107230304.GA7713@iridium.mv.net> <20040108005337.GB3244@jutta.sendmail.com>
Subject: Re: draft-degener-sieve-editheader-01.txt
Date: Thu, 08 Jan 2004 02:59:11 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: owner-ietf-mta-filters@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:ietf-mta-filters-request@imc.org?body=unsubscribe>
> > > 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
- Re: draft-degener-sieve-editheader-01.txt Jutta Degener
- Re: draft-degener-sieve-editheader-01.txt Mark E. Mallett
- Re: draft-degener-sieve-editheader-01.txt Mark E. Mallett
- Re: draft-degener-sieve-editheader-01.txt Jutta Degener
- Re: draft-degener-sieve-editheader-01.txt Nigel Swinson
- Re: draft-degener-sieve-editheader-01.txt Jutta Degener
- Re: draft-degener-sieve-editheader-01.txt Mark E. Mallett
- Re: draft-degener-sieve-editheader-01.txt Philip Guenther
- Re: draft-degener-sieve-editheader-01.txt Mark E. Mallett
- Re: draft-degener-sieve-editheader-01.txt; "refus… Matthew Elvey (FM)
- Re: draft-degener-sieve-editheader-01.txt; "refus… Cyrus Daboo
- Re: draft-degener-sieve-editheader-01.txt; "refus… Cyrus Daboo
- Re: draft-degener-sieve-editheader-01.txt; "refus… Jutta Degener
- Re: draft-degener-sieve-editheader-01.txt; "refus… Nigel Swinson
- Re: draft-degener-sieve-editheader-01.txt; "refus… Mark E. Mallett