Aaron Stone wrote:
Now then, there's the more and more complex patterns... my suggestion is
to accept a new fact:
1. There is always a "user" part, which refers to an account
in the email system.
2. There might be a "detail" part.
3. There might be a couple of detail parts.
# 3 is an interesting idea, but I think it is taking the idea of
flexibility of this extension way too far.
The current document implies that all parts which are not "user" are in
"detail".
A particular implementation can threat "detail" as a structured field,
Sieve variables can be used to extract parts of it.
So let's keep the document the way it is.
[...]
Thanks for reading if you got this far! I hope that my suggested change
is well received. If not, forget that part and just remember that no
matter what the subaddressing scheme is, there has to be some agreement
between the email account lookup and the Sieve script about what parts
of the subaddress are what in the mail system, and that implies at least
a de-facto standard or contract of some kind among the codebases.
I agree with this part.