headers
Internet-Drafts | 2 Mar 2006 21:50
Picon
Favicon

I-D ACTION:draft-ietf-sieve-mime-loop-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Sieve Mail Filtering Language Working Group of the IETF.

	Title		: Sieve Extensions:  MIME Tests, MIME Bodypart Iteration, Replacement and Enclosure
	Author(s)	: T. Hansen, C. Daboo
	Filename	: draft-ietf-sieve-mime-loop-00.txt
	Pages		: 9
	Date		: 2006-3-2
	
   The current Sieve language has no way to look at individual MIME
   parts, looping mechanism, or any way to manipulate those individual
   parts.  This document defines extensions for each of these needs.

   This document is being discussed in the MTA-FILTERS mailing lists,
   ietf-mta-filters <at> imc.org.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sieve-mime-loop-00.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sieve-mime-loop-00.txt".

A list of Internet-Drafts directories can be found in
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Haardt | 3 Mar 2006 15:14
Picon

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


On Fri, Feb 17, 2006 at 03:50:01PM -0500, Internet-Drafts <at> ietf.org wrote:
> 	Title		: Sieve Email Filtering -- Subaddress Extension
> 	Author(s)	: K. Murchison
> 	Filename	: draft-ietf-sieve-rfc3598bis-02.txt
> 	Pages		: 14
> 	Date		: 2006-2-17

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.

Michael
Permalink | Reply | 8 comments |
headers
Ned Freed | 3 Mar 2006 18:03

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


> On Fri, Feb 17, 2006 at 03:50:01PM -0500, Internet-Drafts <at> ietf.org wrote:
> > 	Title		: Sieve Email Filtering -- Subaddress Extension
> > 	Author(s)	: K. Murchison
> > 	Filename	: draft-ietf-sieve-rfc3598bis-02.txt
> > 	Pages		: 14
> > 	Date		: 2006-2-17

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

I suppose you could also use subdomains to encode some of this information
(VERP is an approach, not a particular encoding), but that's not how it is
normally done.

				Ned
Permalink | Reply | 7 comments |
headers
Michael Haardt | 3 Mar 2006 20:17
Picon

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


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.berkeley.edu mailing list is sent to
   God <at> heaven.af.mil, for example, it has the following envelope sender:

      djb-sos-owner-God=heaven.af.mil <at> silverton.berkeley.edu

The " <at> " 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.
(Continue reading)

Permalink | Reply | 6 comments |
headers
Philip Guenther | 3 Mar 2006 21:24
Favicon

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


Michael Haardt <michael <at> freenet-ag.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.berkeley.edu mailing list is sent to
>   God <at> heaven.af.mil, for example, it has the following envelope sender:
>
>      djb-sos-owner-God=heaven.af.mil <at> silverton.berkeley.edu
>
>The " <at> " 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.af.mil> from that address?  If so, what combination of
keyword arguments would do that?  (What if _that_ address was a VERP?)
(Continue reading)

Permalink | Reply | 5 comments |
headers
Michael Haardt | 4 Mar 2006 11:56
Picon

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


On Fri, Mar 03, 2006 at 12:24:14PM -0800, Philip Guenther wrote:
> 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.

You misunderstand me.  The subaddress extension does not split addresses
on its own, but asks the underlying system to perform that operation,
and simply uses the results.  It does not specify if prefix or suffix
strings are to be used, but relies on the underlying system to know
the local convention:

   Note that
   the mechanisms used to define and/or query the separator character
   sequence and sub-part ordering used by the mail system are outside
   the scope of this document.

And things are good that way.

Unfortunately, it says: The only algorithm the underlying system may
perform is to use a separator for splitting the address in parts.

I ask to be less restrictive and allow the underlying system to split
the addresses in whatever way someone may want to configure it.

> > Why? VERP (http://cr.yp.to/proto/verp.txt) is a popular encoding
> > and if you relaxed the encoding specification, Sieve could be
(Continue reading)

Permalink | Reply | 4 comments |
headers
Alexey Melnikov | 4 Mar 2006 00:46
Favicon

Survey of spamtest implementations


Hi folks,
I would like how many server or client implementations support spamtest 
extension as defined in RFC 3685. Please send replies directly to me.

Thanks,
Alexey
Permalink | Reply | 0 comments |
headers
Alexey Melnikov | 4 Mar 2006 01:00
Favicon

Agenda for Sieve WG meeting in Dallas


Hi everyone,
Dallas meeting is approaching, so it is time to talk about agenda for 
Sieve WG meeting.
Can I please see a show of hands (off-list please) about who from 
editors is planning to attend and if a person is not attending, whom he 
wants to nominate as a presenter.
I would also appreciate a short message from each editor about status or 
their documents (recent changes, todo list, open issues).

Alexey

P.S. Both Cyrus and I are planning to attend the meeting.
Permalink | Reply | 0 comments |
headers
Alexey Melnikov | 4 Mar 2006 20:30
Favicon

Tentative agenda for the Sieve WG meeting in Dallas


Ok folks,
Here is a draft agenda for the Dallas IETF meeting:

Agenda

- Introduction (blue sheets, scribe etc) (1 min)
- Agenda Bashing (2 mins)
- Report on completed work (2 mins)
- Spamtest draft status (10 mins)
- Date draft status (5 mins)
- Subaddress draft status (5 mins)
- Regex draft status (5 mins)
- Reject/refuse draft (10 mins)
- MIME loops draft (20 mins)
- Notification draft (20 mins)
- Base spec status, in particular review of
  comparators (draft-newman-i18n-comparator-07.txt) and Sieve (10 mins)
- Other topics:
  Manage Sieve protocol (5 mins)
  Include draft (15 mins)
  Proposals for adding exception handling/optional require to Sieve (10 
mins)

Total: 120 minutes.
===============
The suggested order might look backward, but I would like to discuss 
easy documents first.

The items in the list I am not sure about: Regex (there is a new draft,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Philip Guenther | 5 Mar 2006 07:50
Favicon

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


Michael Haardt <michael <at> freenet-ag.de> writes:
>On Fri, Mar 03, 2006 at 12:24:14PM -0800, Philip Guenther wrote:
...
>> 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.
>
>Users usually do not send VERPs, but MLMs do.  The system that runs
>the MLM would be configured to know which bounces belong to the MLM,
>and set up subaddressing to decode VERP.  Mail that belongs to users
>would be delivered with subaddressing set up as the local convention
>for users is, i.e. <user+detail <at> domain>.

So, the use-case you have in mind for the requested flexibility would be
for sieve scripts running 'in front of' MLMs only?  That's a pretty
specialized application.

>> 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.
>
>If you want ultimate configurability, indeed variables and string
>expressions are needed.  But all I ask for is making the subaddress
>specification less restrictive on issues outsides its scope and change
>it into an abstraction that simply queries an abstract user and detail
>part, not caring about how they are formed.

I guess my concern is that generalizing the wording will make it less
(Continue reading)

Permalink | Reply | 3 comments |

Gmane