Ned Freed writes:
Stephan Bosch writes:
> * RFC 5228 (Sieve) : 5.1. Test address:
> "Implementations MUST restrict the address test to headers that
> contain addresses, but MUST include at least From, To, Cc, Bcc,
> Sender, Resent-From, and Resent-To, and it SHOULD include any other
> header that utilizes an "address-list" structured header body."
> -> Will this cause a compile error, or are the disallowed headers
> simply ignored? My implementation currently considers this to be a
> compile error.
So does mine.
Our implementation does not. We allow address tests on all possible header
fields. The test fails if the field does not contain actual addresses.
<SNIP>Long explanation about why this is wrong.</SNIP>
There is a reason why I pose this as a question. :) I am just trying to
follow the standard here. Your points are valid and they do make me
wonder why this was added in the new Sieve RFC. However, I do think we
should reach some sort of consensus here to prevent ill portability of
scripts that 'address' obscure headers.
> * RFC 5228 (Sieve) : 5.4. Test envelope:
> "The "envelope" test is true if the specified part of the [SMTP] (or
> equivalent) envelope matches the specified key. This specification
> defines the interpretation of the (case insensitive) "from" and "to"
> envelope-parts. Additional envelope-parts may be defined by other
> extensions; implementations SHOULD consider unknown envelope parts an
Again, I give an error at compile time, none at runtime.
We check this at runtime. Changing things to perform a compile time check
wouldn't be difficult, at least in the common case of no variable
substitutions, but since this can't be done when ihave is turned on and
headed towards a situation where the vast majority of scripts we process
ihave, I don't see any point in spending the time to implement this.
> -> Given the variables extension, sometimes the specified envelope
> parts aren't known until runtime. Should invalid ones abort the
> script or is ignoring them a better practice?
A script that manages to do an envelope test on an nonexistant envelope
broken in a fairly fundamental way. This needs to be noted, and the way
that is to throw an error.