headers
Alexey Melnikov | 6 Aug 2007 10:48
Favicon

WGLC on draft-ietf-sieve-mime-loop


Hi,

This message officially starts the Sieve Working Group Last Call for
the following document: 

SIEVE Email Filtering:  MIME part Tests, Iteration, Replacement and Enclosure
<http://www.ietf.org/internet-drafts/draft-ietf-sieve-mime-loop-03.txt>

The Working Group Last Call for this document starts on August 6th and will end on August 20th.

Please send any comments to the Sieve mailing list or directly to me. Please CC Tony Hansen <tony <at> att.com>
and Cyrus Daboo <cyrus <at> daboo.name> in the latter case. Reviews that found no issues are also welcomed, so
if you review the document and find it acceptable, please let the mailing list/authors+me know as well.

Thank you,
Alexey, Sieve WG co-chairs
Permalink | Reply | 9 comments |
headers
Dilyan Palauzov | 6 Aug 2007 17:55

Re: WGLC on draft-ietf-sieve-mime-loop


Hello,

 > 7 Action extract_text

> QUESTION: What do we do if the Content-Transfer-Encoding is anything other than 7bit?

If it is 8bit, we take the :first number characters (not bytes), taking into account the 
"charset=" parameter of the Content-Type header, when presented. If it is base64 or 
quoted-printable, we convert it to 8bit and proceed as if it was 8bit. The same for binary,
 even if the result will be probably useless. (The useless results can happen using base64, 
too, but the possibility is smaller)

> :type, :subtype, :contenttype

What is the obvious advantage of having them, compared to header :contains ? I mean, isn't 
'header :contains "Content-Type" "text/"' as powerful, as 'header :type "Context-Type" 
"text"'? If this was discussed already on this list, could you tell me the starting date?

Със здраве,
Дилян

Alexey Melnikov wrote:
>
> Hi,
>
> This message officially starts the Sieve Working Group Last Call for
> the following document:
> SIEVE Email Filtering: MIME part Tests, Iteration, Replacement and 
> Enclosure
(Continue reading)

Permalink | Reply | 3 comments |
headers
Nigel Swinson | 10 Aug 2007 18:03
Favicon

Naming conventions for Sieve RFCs


Did we decide on a naming convention for Sieve extensions?  We seem to have
either "Sieve Email Filtering: ..." or "Sieve Extension: ..." and I think it
would be helpful to be consistent.  Looking for a precedent from the
existing RFCs we have:

RFC3431 Sieve Extension: Relational Tests. W. Segmuller. December 2002.
     (Format: TXT=12849 bytes) (Status: PROPOSED STANDARD)

RFC3598 Sieve Email Filtering -- Subaddress Extension. K. Murchison.
     September 2003. (Format: TXT=11151 bytes) (Status: PROPOSED STANDARD)

RFC3685 SIEVE Email Filtering: Spamtest and VirusTest Extensions. C.
     Daboo. February 2004. (Format: TXT=17436 bytes) (Status: PROPOSED
     STANDARD)

RFC3894 Sieve Extension: Copying Without Side Effects. J. Degener.
     October 2004. (Format: TXT=9018 bytes) (Status: PROPOSED STANDARD)

http://www.ietf.org/html.charters/sieve-charter.html lists the other
I-Drafts out there for Sieve and I think "Sieve Email Filtering: ..." has
the majority vote just now.  That means we should change these if possible:

http://tools.ietf.org/html/draft-ietf-sieve-variables
Sieve Extension: Variables

http://tools.ietf.org/html/draft-ietf-sieve-notify-08
Sieve Extension: Notifications

http://tools.ietf.org/html/draft-ietf-sieve-3431bis-04
(Continue reading)

Permalink | Reply | 15 comments |
headers
Nigel Swinson | 10 Aug 2007 18:31
Favicon

Re: WGLC on draft-ietf-sieve-mime-loop


WRT to: http://tools.ietf.org/html/draft-ietf-sieve-mime-loop-03 and some
related discussion of http://tools.ietf.org/html/draft-ietf-sieve-body-06

Abstract

I don't think it's necessary to start the abstract by saying what can't be
done with an existing standard.  By stating what this extension offers you
implicitly propose that no other standard offers this.

-   The Sieve email filtering language has no way to examine individual
-   MIME parts or any way to manipulate those individual parts.  However,
-   being able to filter based on MIME content is important.  This
-   document defines extensions for these needs.
+   This document defines extensions to the Sieve email filtering language
+   to permit analysis and manipulation of the MIME body parts of an email
+   message.

1.  Introduction

I don't think it's necessary to justify the current extension based on what
other standards don't allow you to do.  Also while it might be helpful to
refer to other related standards, it seems to just create headaches when you
want to revise the standard later, so I'd suggest:

-   Sieve scripts are used to make decisions about the disposition of an
-   email message.  The base Sieve specification,
-   [I-D.ietf-sieve-3028bis], defines operators for looking at the
-   message headers, such as addresses and the subject.  Other extensions
-   provide access to the body of the message ([I-D.ietf-sieve-body]), or
(Continue reading)

Permalink | Reply | 0 comments |
headers
Nigel Swinson | 10 Aug 2007 18:40
Favicon

Re: WGLC on draft-ietf-sieve-mime-loop


>  > 7 Action extract_text
>
> > QUESTION: What do we do if the Content-Transfer-Encoding is anything
other than 7bit?
>
> If it is 8bit, we take the :first number characters (not bytes), taking
into account the
> "charset=" parameter of the Content-Type header, when presented. If it is
base64 or
> quoted-printable, we convert it to 8bit and proceed as if it was 8bit. The
same for binary,
>  even if the result will be probably useless. (The useless results can
happen using base64,
> too, but the possibility is smaller)

I guess the reason this is a problem is if you hit some 10MB base64 encoded
attachment and are trying to extract the first 100 bytes.  You either have
to decode the whole 10MB, or write some picky code to extract as little text
as possible while decoding legal units of QP/base64 encoding.

With the body test we offer :raw :content :text to decide what kind of
transform is required, which is why I believe extract_text should be moved
to the body spec, and implemented through an optional argument to force the
setting of the match variables.

> > :type, :subtype, :contenttype
>
> What is the obvious advantage of having them, compared to header :contains
? I mean, isn't
(Continue reading)

Permalink | Reply | 0 comments |
headers
Aaron Stone | 10 Aug 2007 19:14
Gravatar

Re: WGLC on draft-ietf-sieve-mime-loop


I like these edits a lot! +1 (with a very large value of 1).

One editing note, recall that RFC's should always use the Oxford comma in
lists of three items or more. I've noted two missing commas below. (Sorry,
this is uber-nit-picking; the RFC Editor should pick these up anyways.)

Aaron

On Fri, Aug 10, 2007, Nigel Swinson <Nigel.Swinson <at> mailsite.com> said:

> 
> WRT to: http://tools.ietf.org/html/draft-ietf-sieve-mime-loop-03 and some
> related discussion of http://tools.ietf.org/html/draft-ietf-sieve-body-06
> 
> Abstract
> 
> I don't think it's necessary to start the abstract by saying what can't be
> done with an existing standard.  By stating what this extension offers you
> implicitly propose that no other standard offers this.
> 
> -   The Sieve email filtering language has no way to examine individual
> -   MIME parts or any way to manipulate those individual parts.  However,
> -   being able to filter based on MIME content is important.  This
> -   document defines extensions for these needs.
> +   This document defines extensions to the Sieve email filtering language
> +   to permit analysis and manipulation of the MIME body parts of an email
> +   message.
> 
> 1.  Introduction
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alexey Melnikov | 11 Aug 2007 11:54
Favicon

Re: WGLC on draft-ietf-sieve-mime-loop


Dilyan Palauzov wrote:

> Hello,
>
> > 7 Action extract_text
>
>> QUESTION: What do we do if the Content-Transfer-Encoding is anything 
>> other than 7bit?
>
> If it is 8bit, we take the :first number characters (not bytes),

Actually 'octet' should be used, as 'character' might use one or more 
octets, depending on charset.

> taking into account the "charset=" parameter of the Content-Type 
> header, when presented. If it is base64 or quoted-printable, we 
> convert it to 8bit and proceed as if it was 8bit. The same for binary,

Agreed.

> even if the result will be probably useless. (The useless results can 
> happen using base64, too, but the possibility is smaller)
>
>> :type, :subtype, :contenttype
>
> What is the obvious advantage of having them, compared to header 
> :contains ? I mean, isn't 'header :contains "Content-Type" "text/"' as 
> powerful,
(Continue reading)

Permalink | Reply | 1 comment |
headers
Troy Benjegerdes | 11 Aug 2007 23:58

sieve-refuse-reject implementations?


Does anyone have an implementation of sieve-refuse-reject that can work
with Postfix, Courier-mta, or Exim?

I have been using courier-mta's localmailfilter 
( http://www.courier-mta.org/localmailfilter.html ) features to run
spamassassin at SMTP-time via maildrop, and I'd like to try to migrate
to something that uses SIEVE since I'd like to have someone other than
myself be able to use SMTP-time reject.

--

-- 
--------------------------------------------------------------------------
Troy Benjegerdes                'da hozer'                hozer <at> hozed.org  

Somone asked me why I work on this free (http://www.fsf.org/philosophy/)
software stuff and not get a real job. Charles Shultz had the best answer:

"Why do musicians compose symphonies and poets write poems? They do it
because life wouldn't have any meaning for them if they didn't. That's why
I draw cartoons. It's my life." -- Charles Shultz
Permalink | Reply | 0 comments |
headers
Kjetil Torgrim Homme | 12 Aug 2007 02:38
Picon
Picon

Re: WGLC on draft-ietf-sieve-mime-loop


On Sat, 2007-08-11 at 10:54 +0100, Alexey Melnikov wrote:
> Dilyan Palauzov wrote:
> > If it is 8bit, we take the :first number characters (not bytes),
> 
> Actually 'octet' should be used, as 'character' might use one or more 
> octets, depending on charset.

please, no.  it's not good that you can't know if you get a garbage
value, ie. a truncated UTF-8 sequence or UCS-2, Big5, Shift-JIS or any
other character set encoding which uses multiple octets for a single
character.

3028 (and 3028bis) already has wording which says transcoding into UTF-8
SHOULD be supported.  it seems natural that this extension takes the
lead of [SIEVE] section 2.7.2.  I wouldn't mind it if this extension
*requires* support similar to what is described in the second paragraph:

      [...] Implementations convert text
      from header fields in all charsets [MIME3] to Unicode, encoded as
      UTF-8, as input to the comparator (see 2.7.3).  Implementations
      MUST be capable of converting US-ASCII, ISO-8859-1, the US-ASCII
      subset of ISO-8859-* character sets, and UTF-8.  Text that the
      implementation cannot convert to Unicode for any reason MAY be
      treated as plain US-ASCII (including any [MIME3] syntax) or
      processed according to local conventions. [...]

I can't see any advantage to allowing an implementation to cop out of
this -- it's not a very streneous requirement, and it would cause
interoperability problems if it is made a quality of implementation
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kjetil Torgrim Homme | 12 Aug 2007 03:05
Picon
Picon

Re: Naming conventions for Sieve RFCs


On Fri, 2007-08-10 at 17:03 +0100, Nigel Swinson wrote:
> Did we decide on a naming convention for Sieve extensions?

I don't think so.  when I brought it up a couple of years ago, there
wasn't much interest in such nitpicking :-)

> We seem to have
> either "Sieve Email Filtering: ..." or "Sieve Extension: ..." and I think it
> would be helpful to be consistent.

I agree.

> Looking for a precedent from the existing RFCs we have:
> 
> RFC3431 Sieve Extension: Relational Tests.
> RFC3598 Sieve Email Filtering -- Subaddress Extension.
> RFC3685 SIEVE Email Filtering: Spamtest and VirusTest Extensions.
> RFC3894 Sieve Extension: Copying Without Side Effects.
> 
> http://www.ietf.org/html.charters/sieve-charter.html lists the other
> I-Drafts out there for Sieve and I think "Sieve Email Filtering: ..." has
> the majority vote just now.

it's odd to count unpublished drafts, IMHO.  I obviously prefer the
shorter "Sieve extension".  But if you're looking at them, note the
"Sieve notification" drafts -- they're not called "Sieve Email
Filtering: mailto notification mechanism" etc.

> That means we should change these if possible:
(Continue reading)

Permalink | Reply | 1 comment |

Gmane