ietf-mta-filters
[Top] [All Lists]

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

2006-03-03 13:38:59

Michael Haardt <michael(_at_)freenet-ag(_dot_)de> 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(_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.

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(_at_)heaven(_dot_)af(_dot_)mil> 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