headers
Internet-Drafts | 4 May 2010 03:30
Picon
Favicon

I-D Action:draft-freed-sieve-notary-08.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 Email Filtering: Delivery Status Notifications and Deliver-By Extensions
	Author(s)       : N. Freed
	Filename        : draft-freed-sieve-notary-08.txt
	Pages           : 15
	Date            : 2010-05-03

This document describes the "envelope-dsn", "redirect-dsn",
"envelope-deliverby", and "redirect-deliverby" extensions to the
Sieve email filtering language.  The "envelope-dsn" and "envelope-
deliverby" extensions provide access to additional envelope
information provided by the delivery status notification and
deliver-by SMTP extensions, respectively.  The "redirect-dsn" and
"redirect-deliverby" extensions extend Sieve's redirect action to
provide control over delivery status notification and deliver-by
parameters, respectively.

Change History (to be removed prior to publication as an RFC

Correct RFC 2852 section reference.

Removed some extraneous [ characters from a couple of figures.

Clarified orcpt decoding.

Changed the ABNF for notary values to disallow spaces.

Fixed several typos.
(Continue reading)

Permalink | Reply | 0 comments |
headers
NED+mta-filters | 4 May 2010 06:13

Re: Status of draft-freed-sieve-notary

I just posted a revised version of this draft. There are three very important
changes I've made in response to various last call comments that the WG needs
to be aware of:

(1) The draft used to be silent on what happens to the envelope from address.
    An issue was raised as to the potential to generate backscatter; I believe
    this issue to be specious but it brought up another, more reasonable
    qeustion: What does it mean to specify the generation of DSNs when the
    destination of those DSNs is implementation dependent? The only sensible
    answer I could come up with was to add text saying that when either
    the redirect-dsn or redirect-deliverby extensions are used, any
    non-empty envelope from MUST be replaced by the address of the sieve owner.

(2) The envelope-deliverby extension only provided by-time information in
    relative form. Given the lack of arithemtic operations in Sieve, this
    form isn't terribly useful and there are cases where an absolute time
    string would be better. I have changed the draft to have both a
    bytimerelative and bytimeabsolute envelope-part and an optional :zone
    arugment. The absolute time is returned in restricted ISO 8601 format.

(3) The redirect-deliverby extension only allowed a relative by-time as well.
    This supports the obvious use-case of "deliver the message in this amount
    of time", but it fails to allow for "deliver before this time" usages.
    So I've changed this to have both :bytimeabsolute and :bytimerelative.

A number of clarifications to the text have also been made; these are noted
in the revision history.

Please review these changes; if the consensus is this goes to far I can always
back them out.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Дилян Палаузов | 5 May 2010 21:46

ietf-mta-filterst <at> imc.org

Hello,

I am now subscribed to both mailing lists
   ietf-mta-filters <at> imc.org and
   sieve <at> ietf.org

I do receive every month two notifications telling me that I am 
subscribed to both lists.

Provided that ieft-mta-filters <at> imc.org moved on 20. Aug to 
sieve <at> ietf.org, does it make sense to be still subscribed to 
ietf-mta-filters <at> imc.org ?

Thanks in advance for the clarification
   Дилян
_______________________________________________
sieve mailing list
sieve <at> ietf.org
https://www.ietf.org/mailman/listinfo/sieve
Permalink | Reply | 2 comments |
headers
Alexey Melnikov | 5 May 2010 22:38
Favicon

Re: ietf-mta-filterst <at> imc.org

Дилян Палаузов wrote:

> Hello,

Hi,

> I am now subscribed to both mailing lists
>   ietf-mta-filters <at> imc.org and
>   sieve <at> ietf.org
>
> I do receive every month two notifications telling me that I am 
> subscribed to both lists.
>
> Provided that ieft-mta-filters <at> imc.org moved on 20. Aug to 
> sieve <at> ietf.org, does it make sense to be still subscribed to 
> ietf-mta-filters <at> imc.org ?

No, you only need to be subscribed to sieve <at> ietf.org.
_______________________________________________
sieve mailing list
sieve <at> ietf.org
https://www.ietf.org/mailman/listinfo/sieve
Permalink | Reply | 1 comment |
headers
Paul Hoffman | 5 May 2010 22:47
Picon

Re: ietf-mta-filterst <at> imc.org

At 9:38 PM +0100 5/5/10, Alexey Melnikov wrote:
ÑËÎþÌ èýÎýÛÁÓ’ wrote:
Hello,

Hi,
I am now subscribed to both mailing lists
  ietf-mta-filters <at> imc.org and
  sieve <at> ietf.org

I do receive every month two notifications telling me that I am subscribed to both lists.
Provided that ieft-mta-filters <at> imc.org moved on 20. Aug to sieve <at> ietf.org, does it make sense to be still subscribed to ietf-mta-filters <at> imc.org ?

No, you only need to be subscribed to sieve <at> ietf.org.

My apologies; I thought I had nuked ietf-mta-filters <at> imc.org after I created the new list. I will do so now.
_______________________________________________
sieve mailing list
sieve <at> ietf.org
https://www.ietf.org/mailman/listinfo/sieve
Permalink | Reply | 0 comments |
headers
Alexey Melnikov | 8 May 2010 12:42
Favicon

Re: Status of draft-freed-sieve-notary

Hi Ned,
[All my comments are with AD hat off, unless otherwise specified]

Ned Freed wrote:

> I just posted a revised version of this draft. There are three very 
> important
> changes I've made in response to various last call comments that the 
> WG needs
> to be aware of:
>
> (1) The draft used to be silent on what happens to the envelope from 
> address.
>    An issue was raised as to the potential to generate backscatter; I 
> believe
>    this issue to be specious but it brought up another, more reasonable
>    qeustion: What does it mean to specify the generation of DSNs when the
>    destination of those DSNs is implementation dependent? The only 
> sensible
>    answer I could come up with was to add text saying that when either
>    the redirect-dsn or redirect-deliverby extensions are used, any
>    non-empty envelope from MUST be replaced by the address of the 
> sieve owner.

Agreed.

Looking at the newly added section 7.1:

7.1.  MAIL FROM address selection

   RFC 5228 does not require any particular envelope sender address be
   associated with redirected messages.  However, the redirect-deliverby
   extension, like the redirect-dsn extension, isn't terribly useful if
   the place where any delivery status notifications are sent isn't
   known.  Accordingly, when :bymode is specified and the envelope

I think you should be using :bytimerelative or :bytimeabsolute here, as :bymode is optional.

   sender address isn't empty, implementations MUST set the envelope
   sender address to the address of the sieve owner.

> (2) The envelope-deliverby extension only provided by-time information in
>    relative form. Given the lack of arithemtic operations in Sieve, this
>    form isn't terribly useful and there are cases where an absolute time
>    string would be better. I have changed the draft to have both a
>    bytimerelative and bytimeabsolute envelope-part and an optional :zone
>    arugment. The absolute time is returned in restricted ISO 8601 format.

This looks sensible.

Two side notes:
a). Maybe we should add some basic arithmetics to Sieve. But this 
document is not the right place for that.
b). Do we really need both relative and absolute options? (I don't have 
a good answer.)

> (3) The redirect-deliverby extension only allowed a relative by-time 
> as well.
>    This supports the obvious use-case of "deliver the message in this 
> amount
>    of time", but it fails to allow for "deliver before this time" usages.
>    So I've changed this to have both :bytimeabsolute and :bytimerelative.
>
> A number of clarifications to the text have also been made; these are 
> noted
> in the revision history.
>
> Please review these changes; if the consensus is this goes to far I 
> can always
> back them out.
>
> There's also the question of whether or not this warrants a new last call.

(AD hat on) I am afraid it does. The changes are just to drastic to 
approve as is.

Some additional comments on the latest version:

1) The following extensions should be listed as Informative references:

  "date", "variables"

2) In Section 5.1:

   require ["envelope", "envelope-deliverby", "relational", "date"

Missing comma after "date".

            "variables"];

3) An example using :zone in envelope test would be useful as well.

> I'll leave that decision to those above my pay grade ;-)

I will share my bonus with you once I get it ;-).

_______________________________________________
sieve mailing list
sieve <at> ietf.org
https://www.ietf.org/mailman/listinfo/sieve
Permalink | Reply | 1 comment |
headers
NED+mta-filters | 8 May 2010 17:32

Re: Status of draft-freed-sieve-notary

> Hi Ned,
> [All my comments are with AD hat off, unless otherwise specified]

> Ned Freed wrote:

> > I just posted a revised version of this draft. There are three very
> > important
> > changes I've made in response to various last call comments that the
> > WG needs
> > to be aware of:
> >
> > (1) The draft used to be silent on what happens to the envelope from
> > address.
> >    An issue was raised as to the potential to generate backscatter; I
> > believe
> >    this issue to be specious but it brought up another, more reasonable
> >    qeustion: What does it mean to specify the generation of DSNs when the
> >    destination of those DSNs is implementation dependent? The only
> > sensible
> >    answer I could come up with was to add text saying that when either
> >    the redirect-dsn or redirect-deliverby extensions are used, any
> >    non-empty envelope from MUST be replaced by the address of the
> > sieve owner.

> Agreed.

> Looking at the newly added section 7.1:

> 7.1.  MAIL FROM address selection

>    RFC 5228 does not require any particular envelope sender address be
>    associated with redirected messages.  However, the redirect-deliverby
>    extension, like the redirect-dsn extension, isn't terribly useful if
>    the place where any delivery status notifications are sent isn't
>    known.  Accordingly, when :bymode is specified and the envelope

> I think you should be using :bytimerelative or :bytimeabsolute here, as
> :bymode is optional.

Yep, that's what it should say.

>    sender address isn't empty, implementations MUST set the envelope
>    sender address to the address of the sieve owner.

> > (2) The envelope-deliverby extension only provided by-time information in
> >    relative form. Given the lack of arithemtic operations in Sieve, this
> >    form isn't terribly useful and there are cases where an absolute time
> >    string would be better. I have changed the draft to have both a
> >    bytimerelative and bytimeabsolute envelope-part and an optional :zone
> >    arugment. The absolute time is returned in restricted ISO 8601 format.

> This looks sensible.

> Two side notes:
> a). Maybe we should add some basic arithmetics to Sieve. But this
> document is not the right place for that.

I agree; but it's a tricky thing to add cleanly given the inability to
change the basic syntax.

> b). Do we really need both relative and absolute options? (I don't have
> a good answer.)

I'm fairly sure we want buth on redirect. I'm less convinced about
envelope, but OTOH I didn't see much difficulty in having both forms
available.

> > (3) The redirect-deliverby extension only allowed a relative by-time
> > as well.
> >    This supports the obvious use-case of "deliver the message in this
> > amount
> >    of time", but it fails to allow for "deliver before this time" usages.
> >    So I've changed this to have both :bytimeabsolute and :bytimerelative.
> >
> > A number of clarifications to the text have also been made; these are
> > noted
> > in the revision history.
> >
> > Please review these changes; if the consensus is this goes to far I
> > can always
> > back them out.
> >
> > There's also the question of whether or not this warrants a new last call.

> (AD hat on) I am afraid it does. The changes are just to drastic to
> approve as is.

I have to agree.

> Some additional comments on the latest version:

> 1) The following extensions should be listed as Informative references:

>   "date", "variables"

Agreed. Added.

> 2) In Section 5.1:

>    require ["envelope", "envelope-deliverby", "relational", "date"

> Missing comma after "date".

>             "variables"];

Fixed.

> 3) An example using :zone in envelope test would be useful as well.

OK, how about:

require ["envelope", "envelope-deliverby", "relational", "date",
         "variables"];

# If the message didn't make it in time file it according to when it
# should have been received
if envelope :matches :zone "+0000" "bytimeabolute "*T*:*:*" {
    set "bdate" "${0}";
    set "bhour" "${2}";
    if currentdate :zone "+0000" :value "lt" "iso8601" "${bdate}")
        fileinto "missed-${bhour}";
    }
}

I'll defer posting a revision so others can have a chance to review and suggest
additional changes.

				Ned
_______________________________________________
sieve mailing list
sieve <at> ietf.org
https://www.ietf.org/mailman/listinfo/sieve
Permalink | Reply | 0 comments |
headers
The IESG | 10 May 2010 15:55
Picon
Favicon

Second Last Call: draft-freed-sieve-notary (Sieve Email Filtering: Delivery Status Notifications and Deliver-By Extensions) to Proposed Standard

The IESG has received a request from the Sieve Mail Filtering Language WG 
(sieve) to consider the following document:

- 'Sieve Email Filtering: Delivery Status Notifications and Deliver-By 
   Extensions '
   <draft-freed-sieve-notary-08.txt> as a Proposed Standard

The purpose of the Second IETF Last Call is to confirm some major
syntactic change resulting from a SecDir review.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
ietf <at> ietf.org mailing lists by 2010-05-24. Exceptionally, 
comments may be sent to iesg <at> ietf.org instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-freed-sieve-notary-08.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15894&rfc_flag=0

_______________________________________________
sieve mailing list
sieve <at> ietf.org
https://www.ietf.org/mailman/listinfo/sieve
Permalink | Reply | 0 comments |
headers
Aaron Stone | 10 May 2010 23:28
Gravatar

WG conflict research tool -- Fwd: resend - poll request

If anybody has found themselves involved in a working group conflict, please check out this survey (see message below) and offer your input on a research project into an automated WG conflict detection tool.

Cheers,
Aaron

---------- Forwarded message ----------
From: Scott O. Bradner <sob <at> harvard.edu>
Date: Tue, May 4, 2010 at 10:04 AM
Subject: resend - poll request
To: wgchairs <at> ietf.org


working group chairs:

This is the resend of the pointer to the survey that I talked about
during the WG Chairs lunch in Anaheim – sorry for the delay

Please take a look & if you are comfortable doing so, please send a
pointer to your WG discussion list

Thanks

Scott

=== resend====

We need your support to our project that develops an open-source tool
monitoring the status of conflicts in a virtual working group (WG).
This tool will be particular well suited to monitoring conflict
resolution in IETF WGs as well as post mortem analysis of past WGs. Its
goal is to automatically analyze IETF WG discussion archives to
determine the amount of conflict and how effective this conflict is
being (has been) resolved.  As the first step, we need to understand the
relationship between the conflicts in a working group and the structure
of the communication network in that group. While having conflicts is
not necessarily a bad thing for a team, some conflicts could be
escalated into disasters. We are interested in finding the communication
patterns related to the evolution of group conflicts. Results from this
study will provide the base for the development of the tool that helps
working group chairs to decide when to intervene with an internal
conflict before it becomes irreversibly negative as well as being a tool
that may help determine where there is consensus on a particular topic.

We would like your help in understanding the level of conflicts within
your working groups and how the conflicts affect productivity and group
members’ perception on the working group. It will be greatly appreciated
if you could ask your WG members to anonymously fill a short survey at

https://spreadsheets.google.com/viewform?hl=en&formkey=dExTbEU5QmRncnhFbjhQUVR4bzBGMEE6MA

Thank you!

Best Regards,

Bin Zhu, Mark Gaynor, Scott Bradner, and Jialun Qin



_______________________________________________
sieve mailing list
sieve <at> ietf.org
https://www.ietf.org/mailman/listinfo/sieve
Permalink | Reply | 0 comments |
headers
Dilyan Palauzov | 16 May 2010 20:38

Re: Last Call: draft-freed-sieve-notary (Sieve Email Filtering: Delivery Status Notifications and Deliver-By Extensions) to Proposed Standard

Hello,

For draft-george-sieve-vacation-time it was agreed, that providing  
"vacation-seconds" in "require" implies that "vacation" is also  
specified.

My suggestion is to include in draft-freed-sieve-notary that require  
"envelope-dsn"/"envelope-deliverby" implies require "envelope".

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

----- Message from iesg-secretary <at> ietf.org ---------
     Date: Thu, 25 Mar 2010 12:49:21 -0700 (PDT)
     From: The IESG <iesg-secretary <at> ietf.org>
Reply-To: ietf <at> ietf.org
  Subject: [sieve] Last Call: draft-freed-sieve-notary (Sieve Email  
Filtering: Delivery Status Notifications and Deliver-By Extensions) to  
Proposed Standard
       To: IETF-Announce <ietf-announce <at> ietf.org>
       Cc: sieve <at> ietf.org

> The IESG has received a request from the Sieve Mail Filtering Language WG
> (sieve) to consider the following document:
>
> - 'Sieve Email Filtering: Delivery Status Notifications and Deliver-By
>    Extensions '
>    <draft-freed-sieve-notary-07.txt> as a Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send substantive comments to the
> ietf <at> ietf.org mailing lists by 2010-04-08. Exceptionally,
> comments may be sent to iesg <at> ietf.org instead. In either case, please
> retain the beginning of the Subject line to allow automated sorting.
>
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-freed-sieve-notary-07.txt
>
>
> IESG discussion can be tracked via
> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15894&rfc_flag=0
>
> _______________________________________________
> sieve mailing list
> sieve <at> ietf.org
> https://www.ietf.org/mailman/listinfo/sieve
>

----- End message from iesg-secretary <at> ietf.org -----

_______________________________________________
sieve mailing list
sieve <at> ietf.org
https://www.ietf.org/mailman/listinfo/sieve
Permalink | Reply | 2 comments |

Gmane