On Tue, 2005-07-05 at 16:52 -0400, Mark E. Mallett wrote:
2.2. Whitespace
> Whitespace is used to separate tokens. Whitespace is made up of
> tabs, newlines (CRLF, never just CR or LF), and the space character.
> The amount of whitespace used is not significant.
This is specifically about whitespace in the Sieve language. So... how
many implementations violate this? i.e., does everyone generate an
error if a script's whitespace contains a naked CR or LF ?
does it matter? this text is unchanged from RFC 3028, so it will not
affect conformance.
I see no "MUST generate an error" clause here, so as far as I'm concerned the
handling of bare CR and bare LF means you have a nonconformant script, but how
implementations handle this particular form of nonconformance is undefined.
Attempting to nail this down to a "MUST generate an error" would be a huge
mistake IMO, given the use of bare LF and bare CR as the default line
terminators on many systems. And I really don't want to repeat the whole
"canonical format versus local storage format" discussion again, thank you very
much. So let's let this particular sleeping dog lie, OK?
2.10.6. Errors
> When an error happens, implementations MUST notify the user that an
> error occurred, which actions (if any) were taken, and do an implicit
> keep.
Probably extremely nit-picky, but I've always wondered when I read
this "what user, and how do we notify them?" Some users have no
access to anything other than their mailboxes. I suspect that many
implementations will do some system-wide logging, which notifies the
admin, but not the user.
good question. delivering an error report to INBOX in addition to the
message is one way of solving this, but does anyone do this?
We do. Our implementation has the concept of a "responsible address" that's
attached to each sieve script. When an error occurs this address is notified of
the problem. For user sieves this is the user's own address, system sieves have
the main system postmaster as the responsible address, and so on.
Of course the delivery of such notifications has to be done in a way
that doesn't go through sieve processing and generate an exponentially
growing loop.
Other random comments:
The spec provides no way to access the "From_" line (which is the
"From<sp>" line with no colon that is added by some mail software.
While it's not part of RFC2822, and admittedly a minor concern at
best, that 'header' is often there, but inaccessible. I have no
solution, other than perhaps making "From_" a special header name.
we have envelope "from" for the e-mail address. we don't have anything
for the delivery date, but I suspect Ned is considering that for his
"date" extension.
Actually I'm not. The current time, yes, but since the time of sieve evalaution
isn't exactly specified in terms of its relationship to final delivery it
doesn't make sense to have this as part of a general date extension. It would
at best be another, separate extension.
The 'variables' extension has to specify greedy/non-greedy ":matches" ;
this really ought to be in 3028 so that extensions can consistently
follow whatever rule there is; although, again, it might fail the
"non-substantive" test.
I don't think this behaviour description is relevant for the main spec.
it can not be observed without the variables extension.
Yes, exactly so. This could easily come back to bite us when we need to move to
draft.
Ned