ietf-mta-filters
[Top] [All Lists]

Re: Questions regarding RFC 5228

2008-10-20 18:15:21

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
> error."

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 we're headed towards a situation where the vast majority of scripts we process use
ihave, I don't see any point in spending the time to implement this.
I agree.

>   -> 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 part is broken in a fairly fundamental way. This needs to be noted, and the way you do
that is to throw an error.
Ok.

Regards,

Stephan

<Prev in Thread] Current Thread [Next in Thread>