On Wed, Mar 24, 2010 at 2:12 AM, Arnt Gulbrandsen
<arnt(_at_)gulbrandsen(_dot_)priv(_dot_)no> wrote:
Hi,
an introduction first, as rationale.
Several years ago I proofread parts of book which, among other things,
explained how to write sieve scripts. The authors used the header test
throughout. Prose like this:
To test whether an address is addressed to fred(_at_)example(_dot_)org,
you write
if header "to" :is "fred(_at_)example(_dot_)org" {
fileinto "roles/fred";
}
I explained that 'if address' was the right test. They didn't believe that
header was wrong, and showed me examples proving its correctness, eventually
switching to from :is to :contains (mishandling alfred@).
Not sure what the printed book said.
People do misuse header in that way quite often. I've corrected the error in
internet-drafts several times, and recently (a few months ago) I saw a
misused 'if header' in a published RFC.
When even the sieve WG members misuse a test, it's time to adapt the test to
human reality.
So here's my proposal:
1. In the next iteration of base Sieve RFC, either allow or recommend
testing address fields as though 'if address' were specified, even if 'if
header' is specified.
Based on a the heuristic of seeing an @ sign?
I have to say I think this is a *really* bad idea. While I am sympathetic to
the issue here, there are plenty of cases where I want to test an address field
using header and not address. Obvious one: Syntactically invalid fields that
address cannot parse.
2. Publish this an erratum now.
Even stronger objection. THis is in no way, shape, or form an error in the
specificaiton, and it is a serious abuse of the errata process to make a
fundamental change to Sieve semantics.
[Simplistic question to elicit details:]
When and how do 'if address' and 'if header :contains' differ?
Perhaps this table is what we publish as the erratum, explaining that
yes, it will sometimes work, but here's how it's going to break.
A discussion of thise issues strikes me as an excellent thing to put in a
"uses of Sieve " document. That's the way to attack this issue, not by
mucking up the clean semantics we currently have.
Ned
_______________________________________________
sieve mailing list
sieve(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/sieve