[Top] [All Lists]

A question/comment on the envelope test regarding envelope parts

2008-07-27 14:40:45


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

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