Re: I-D ACTION:draft-ietf-sieve-rfc3598bis-02.txt

[Philip Guenther <guenther+mtafilters@xxxxxxxxxxxx>]

Michael Haardt <michael@xxxxxxxxxxxxx> writes:
...
>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@xxxxxxxxxxxxxxxxxxxxxx mailing list is sent to
>   God@xxxxxxxxxxxxx, for example, it has the following envelope sender:
>
>      djb-sos-owner-God=heaven.af.mil@xxxxxxxxxxxxxxxxxxxxxx
>
>The "@" in the list member is replaced by "=".  A very primitive encoding,
>but an encoding, whereas the subaddress draft requires substrings.

My interpretation is that for that example address, the sieved handling
mail for silverton.berkeley.edu would follow the qmail practice and
split the localpart on the first '-', such that :user would specify
'djb' and :detail would specify 'sos-owner-God=heaven.af.mil'.  If you
disagree or desire otherwise, please describe the additional (or
alternative) processing you're looking for.

<from a previous message>
> 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.

You're looking for a means in sieved to extract the address
<God@xxxxxxxxxxxxx> from that address?  If so, what combination of
keyword arguments would do that?  (What if _that_ address was a VERP?)

Note that you can already extract that address using variables.  Doing
so requires knowledge of what prefixes should be stripped ala
"sos-owner-" in this case.  And no, you can't strip on the last '-'
before the '=' as the wrapped address may have a '-' in its localpart.


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

I didn't think VERPs were an all-or-nothing choice.  A user may send
some messages with VERP-style address and others with random tags in the
subaddress portion.  Please explain how a system that 'decoded' VERPs
would support that.

VERPs are a optional encoding inside the subaddress encoding, ergo
decoding of them should be separately performed or requested so that
access to both levels can be provided.


Philip Guenther