Hello,
I am currently working towards the first release of a new Sieve
implementation by doing an extensive standards compliance review of all
that I've implemented thus far. Among others, I have one question about
the envelope test that also has some relevance to the new notary
extension that you are about to discuss in Dublin.
According to section 5.4 of the main Sieve specification (rfc5228), the
envelope test can be extended with support for new envelope parts. The
ones specified in that main document are both addresses and thus the
ADDRESS-PART argument makes perfect sense. However, due to its
extendability, I started wondering what would happen if one were to
extend the envelope test with envelope parts that do not represent an
address in the sense of rfc(2)822. Today I noticed that that is exactly
what the notary extension does.
Currently, my implementation would mangle the non-address envelope part
through the address part processing, which for instance for the :all
address part tries to normalize the address to the string
"local_part(_at_)domain" before string comparison.
AFAIK such normalization isn't called for anywhere in RFC 5228. Indeed, the RFC
goes out of its way to allow :all to be used to perform tests on syntactically
invalid envelope field values. So if your implementation attempts some sort of
normalization, fails, and ends up with something other than the original
string, I'd have to call that broken.
The only processing you're supposed to do is the removal of source routes from
fields that allow them. (It wouldn't hurt to clarify that this shouldn't change
a syntactically invalid stuff in the next revision.)
Given the fact that the
rfc 5228 states that 'If an optional address-part is omitted, the
default is ":all".' (section 2.7.4), there is (in my view) currently no
standardized way around this problem.
I disagree. To the extent this is an issue, it is a consequence of an
implementation choice you made. That choice already isn't correct if it
prevents :all from being used with syntactically invalid addresses and it won't
be correct for the new fields the notary draft adds.
The new notary draft does not mention the interaction with address parts
either. In my opinion it would be best to prohibit the use of an
ADDRESS-PART parameter for an envelope test that involves envelope parts
that represent no addresses and let the matching act on unprocessed
string values.
Since :localpart or :domain make no sense on anything other than an address
field, this seems like a reasonable restriction to me.
Ned