Subject: Re: Question concerning subaddress extension

From: Michael Haardt <[email-masked]>
Date: Wed, 16 Mar 2005 11:41:22 +0100

> 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" "[email-masked]" ...
>
> or even
>
>     if envelope :matches "to" "*+foo@*" ....
>
> 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.

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.

Michael

---

From: [email-masked]
Date: Wed, 16 Mar 2005 06:27:25 -0800 (PST)

> 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.

> encoding to anything but the envelope "to" is likely to give bad results.

Yep. And we probably should say as much.

				Ned

---

From: Matthew Elvey <[email-masked]>
Date: Mon, 21 Mar 2005 02:50:35 -0800

>structure. Nothing precludes the use of any legal character or characters
Example: It might be useful for BATV, where there is a sub-part in the 
middle.  It might be nice if the extension was defined such that it 
could work on BATV* addresses, e.g.  could see that joe-user is the 
:user part of sig-scheme=joe-user/[email-masked], etc.
Subaddress is currently RFC3598, and has 4 implementations