On Fri, Mar 03, 2006 at 09:03:05AM -0800, Ned Freed wrote:
This draft allows both prefix and suffix encoding, but still requires
both user and detail part to be substrings of the local part.
Why? VERP (http://cr.yp.to/proto/verp.txt) is a popular encoding
and if you relaxed the encoding specification, Sieve could be
used to decode it. A filter in front of a MLM may be very useful.
I fail to see the mismatch. In a VERP scheme the user part tells you the name
of the list whie the detail part tells you the address that failed.
Quoting DJB:
Here is how VERPs work: each recipient of the message sees a
different envelope sender address. When a message to the
djb-sos(_at_)silverton(_dot_)berkeley(_dot_)edu mailing list is sent to
God(_at_)heaven(_dot_)af(_dot_)mil, for example, it has the following
envelope sender:
djb-sos-owner-God=heaven(_dot_)af(_dot_)mil(_at_)silverton(_dot_)berkeley(_dot_)edu
The "@" in the list member is replaced by "=". A very primitive encoding,
but an encoding, whereas the subaddress draft requires substrings.
To me, a subaddress is additional information encoded in the address.
We already recognized that in general, subaddress decoding can only
be done by receiving system for its own addresses. If that involves
splitting strings, translating characters or performing cryptographic
operations, should not be of any concern to the extension that allows
access to the decoded user and detail part.
Michael