On Tue, Jul 05, 2005 at 05:46:18PM -0700, Ned Freed wrote:
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?
Oh- I had forgotten that you asked that, when I wrote my other response,
sorry. I have a hard time letting go that the spec mandates something
that is probably impossible to follow, and likely derives from something
that's not relevant (i.e., wire format). But other than making this
side comment, I will indeed let it go :-)
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?
I do something like that, in a way that's not very clean and I'm not
very proud of, which is one reason I asked the question.. I file any
error message text along with the same message that caused it. (We also
have a personal logfile facility, but that's not guaranteed to be accessible
by the end user, nor is the end user likely to check it very often.)
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.
That sounds like an interesting idea and is probably worth pursuing as
an alternative. Thanks..
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.
I was talking about accessing the header field in same ways that others
can be accessed, not other ways of getting at the specific parts of that
field that we might predict people might want. I've seen occasions
where script writers either want to suppress the line if supplied, or
add one if not, e.g.:
if exists "From_" { deleteheader "From_" };
as a very simple case. Knowing that you can't access that (admittedly
fake) is a thing by itself, without having to say all the things that
you might want to do with it. Anyway it was simply on my collected list
of known issues that I was looking at while making the posting.
-mm-