I think the key issue here is the intent underlying the subaddress
extension.
If the only intent is to slightly simplify something like:
if envelope :is "to" "ned+foo(_at_)mrocheck(_dot_)com" ...
or even
if envelope :matches "to" "*+foo(_at_)*" ....
we haven't accomplished much. But the real purpose of the subaddress
extension
is to avoid having to explicitly code separator rules in the sieve script.
Portability, in other words. If we then change the subaddress extension
so you can specify the separator, we've in effect undone the primary
reason for having the extension.
I agree entirely: Boldly claiming that people use only suffixes as
subaddress, I was instantly proved wrong by one ISP that uses prefixes
with a dot as seperator. Speaking of portability, I think the subaddress
extension should not specifically talk about suffixes or even greedy
matching, but really leave subaddress encoding entirely to the system.
Very good point. Nothing in principle prevents a subaddress from appearing
as a prefix, or in the middle, or as a component of a more complex
structure. Nothing precludes the use of any legal character or characters
as a separator.
As such, it needs to be clear that any talk about how subaddresses
are encoded is only intended to be an exmaple, not a specification of
how implementations have to work.
Its true value would be to be able to refer to a subaddress on different
systems in the same way, and given the differences, applying the local
encoding to anything but the envelope "to" is likely to give bad results.
Yep. And we probably should say as much.
Ned