headers
Mark E. Mallett | 8 Jan 2004 00:03

Re: draft-degener-sieve-editheader-01.txt


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
(Continue reading)

Permalink | Reply | 505 comments |
headers
Mark E. Mallett | 8 Jan 2004 00:56

Re: draft-degener-sieve-body-02.txt


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
Permalink | Reply | 1 comment |
headers
Jutta Degener | 8 Jan 2004 01:53
Favicon

Re: draft-degener-sieve-editheader-01.txt


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.
(Continue reading)

Permalink | Reply | 504 comments |
headers
Jutta Degener | 8 Jan 2004 02:50
Favicon

Re: draft-degener-sieve-body-02.txt


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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Nigel Swinson | 8 Jan 2004 03:59
Favicon

Re: draft-degener-sieve-editheader-01.txt


> > >    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
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jutta Degener | 8 Jan 2004 05:03
Favicon

Re: draft-degener-sieve-editheader-01.txt


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
Permalink | Reply | 0 comments |
headers
Mark E. Mallett | 16 Jan 2004 00:55

Re: draft-degener-sieve-editheader-01.txt


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
(Continue reading)

Permalink | Reply | 10 comments |
headers
Jutta Degener | 16 Jan 2004 01:50
Favicon

Re: draft-degener-sieve-editheader-01.txt


> 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
(Continue reading)

Permalink | Reply | 3 comments |
headers
Mark E. Mallett | 16 Jan 2004 03:52

Re: draft-degener-sieve-editheader-01.txt


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.
> >
(Continue reading)

Permalink | Reply | 2 comments |
headers
Philip Guenther | 16 Jan 2004 05:35
Favicon

Re: draft-degener-sieve-editheader-01.txt


"Mark E. Mallett" <mem <at> mv.mv.com> 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
(Continue reading)

Permalink | Reply | 1 comment |

Gmane