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. 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.
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. At the very least I think that this issue needs to be
dealt with explicitly in a future version of rfc 5228 and possibly also
in the new notary specification.
In case I've missed something that voids this issue, any clarification
is greatly appreciated.
Best regards,
--
Stephan Bosch
stephan(_at_)rename-it(_dot_)nl