Filtering messages in MTAs

ned.freed | 30 Jul 2004 17:18

Re: lunch/bar bof for mta-filters?

> Hi ned.freed <at> mrochek.com,

> --On Friday, July 30, 2004 7:26 AM -0700 ned.freed <at> mrochek.com wrote:

> >> Sounds good, but I am only available for Wednesday lunch.
> >
> > Wednesday lunch works for me.

> That suits me too. I will shortly post a list of drafts and their status
> here so we can see what needs to be discussed.

Random thought: Perhaps it is time to consider forming a sieve
working group. The goals of the group would be carefullly limited to:

(1) Progressing the base sieve specification to draft. (Note that this
    means no significant changes or additions.)

(2) Finishing various sieve I-Ds already on the table.

What do people think about the idea?

				Ned

Rob Siemborski | 30 Jul 2004 17:58

Picon

Re: lunch/bar bof for mta-filters?


On Fri, 30 Jul 2004 ned.freed <at> mrochek.com wrote:

> Random thought: Perhaps it is time to consider forming a sieve
> working group. The goals of the group would be carefullly limited to:
>
> (1) Progressing the base sieve specification to draft. (Note that this
>   means no significant changes or additions.)
>
> (2) Finishing various sieve I-Ds already on the table.
>
> What do people think about the idea?

I strongly support this idea -- I think that holding the working group 
accountable for getting the drafts published is the only way we'll ever be 
able to see any of these documents finished.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 207 * rjs3 <at> andrew.cmu.edu * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O-
M-- V-- PS+ PE+ Y+ PGP+ t+ <at>  5+++ X- R <at>  tv-- b+ DI+++ D++ G e++ h+ r- y?
------END GEEK CODE BLOCK-----

Cyrus Daboo | 30 Jul 2004 17:56

Re: lunch/bar bof for mta-filters?

Hi ned,

--On Friday, July 30, 2004 8:18 AM -0700 ned.freed <at> mrochek.com wrote:

>> That suits me too. I will shortly post a list of drafts and their status
>> here so we can see what needs to be discussed.
>
> Random thought: Perhaps it is time to consider forming a sieve
> working group. The goals of the group would be carefullly limited to:
>
> (1) Progressing the base sieve specification to draft. (Note that this
>     means no significant changes or additions.)
>
> (2) Finishing various sieve I-Ds already on the table.
>
> What do people think about the idea?

I've been thinking the same thing myself. I think getting to draft status 
is a worthy effort and probably is best done under the auspices of a WG. 
Other extensions that have wide deployment right now also ought to be part 
of any WG charter.

My only issue with draft status is whether all the normative references are 
also at draft. The current SIEVE RFC pre-dates the normative/non-normative 
references split. However it does look like all the relevant ones are at 
draft so we ought to be OK.

I am also interested in knowing if there is any interaction with marid/asrg 
that we ought to consider (e.g. SIEVE tests for SPF-type information that

(Continue reading)

ned.freed | 30 Jul 2004 18:14

Re: lunch/bar bof for mta-filters?


> --On Friday, July 30, 2004 8:18 AM -0700 ned.freed <at> mrochek.com wrote:

> >> That suits me too. I will shortly post a list of drafts and their status
> >> here so we can see what needs to be discussed.
> >
> > Random thought: Perhaps it is time to consider forming a sieve
> > working group. The goals of the group would be carefullly limited to:
> >
> > (1) Progressing the base sieve specification to draft. (Note that this
> >     means no significant changes or additions.)
> >
> > (2) Finishing various sieve I-Ds already on the table.
> >
> > What do people think about the idea?

> I've been thinking the same thing myself. I think getting to draft status
> is a worthy effort and probably is best done under the auspices of a WG.
> Other extensions that have wide deployment right now also ought to be part
> of any WG charter.

Absolutely. FWIW, the two that concern me most are the two Vs: Vacation and
variables. The first has been around way too long, and the second is way too
useful.

Do you think the managesieve stuff would also be appropriate?

> My only issue with draft status is whether all the normative references are
> also at draft. The current SIEVE RFC pre-dates the normative/non-normative
> references split. However it does look like all the relevant ones are at

(Continue reading)

Cyrus Daboo | 30 Jul 2004 18:53

Re: lunch/bar bof for mta-filters?


Hi ned.freed <at> mrochek.com,

--On Friday, July 30, 2004 9:14 AM -0700 ned.freed <at> mrochek.com wrote:

>
>> --On Friday, July 30, 2004 8:18 AM -0700 ned.freed <at> mrochek.com wrote:
>
>> >> That suits me too. I will shortly post a list of drafts and their
>> >> status here so we can see what needs to be discussed.
>> >
>> > Random thought: Perhaps it is time to consider forming a sieve
>> > working group. The goals of the group would be carefullly limited to:
>> >
>> > (1) Progressing the base sieve specification to draft. (Note that this
>> >     means no significant changes or additions.)
>> >
>> > (2) Finishing various sieve I-Ds already on the table.
>> >
>> > What do people think about the idea?
>
>> I've been thinking the same thing myself. I think getting to draft status
>> is a worthy effort and probably is best done under the auspices of a WG.
>> Other extensions that have wide deployment right now also ought to be
>> part of any WG charter.
>
> Absolutely. FWIW, the two that concern me most are the two Vs: Vacation
> and variables. The first has been around way too long, and the second is
> way too useful.
>

(Continue reading)

Simon Josefsson | 30 Jul 2004 17:42

Re: lunch/bar bof for mta-filters?

ned.freed <at> mrochek.com writes:

> Random thought: Perhaps it is time to consider forming a sieve
> working group. The goals of the group would be carefullly limited to:
>
> (1) Progressing the base sieve specification to draft. (Note that this
>     means no significant changes or additions.)
>
> (2) Finishing various sieve I-Ds already on the table.
>
> What do people think about the idea?

If this would mean faster progress, I'm for it.

Would it be possible to publish the (expired?) ManageSieve protocol
draft through that venue as well?  It appear to be gaining users,
albeit slowly.  I believe it is a better solution than any of the
other solutions that has been proposed, and that it deserve
publication.  Having done multiple implementations of it, I have some
vested interest in it.

Thanks,
Simon

Alexey Melnikov | 30 Jul 2004 17:31

Re: lunch/bar bof for mta-filters?


ned.freed <at> mrochek.com wrote:

> Random thought: Perhaps it is time to consider forming a sieve
> working group. The goals of the group would be carefullly limited to:
>
> (1) Progressing the base sieve specification to draft. (Note that this
>    means no significant changes or additions.)
>
> (2) Finishing various sieve I-Ds already on the table.
>
> What do people think about the idea? 

If this helps to get Sieve variables published (I am being selfish here, 
of course ), than I agree.

Alexey

Kjetil Torgrim Homme | 31 Jul 2004 19:21

Picon

Picon

variables extension redux


On fre, 2004-07-30 at 16:31 +0100, Alexey Melnikov wrote:
> If this helps to get Sieve variables published (I am being selfish here, 
> of course ), than I agree.

I'm sorry, but I've lost track.  what should be done about it?  there
are some open issues in it, but they don't seem very hard problems,
really.  I apologise if I have left out criticisms, it is not
intentional, my memory isn't so good.

=== excerpt ===
0.3.  Open Issues

b)   this extension is particularily useful if fileinto creates new
     folders on demand.  [SIEVE] doesn't prohibit this, and currently
     some implementations will create new folders automatically, others
     won't.

[out of scope, an explicit :createfolder for fileinto should be a
separate extension.  this can be closed.]

d)   the EDITHEADER draft includes an action that needs the unexpanded
     string to be passed to the procedure, since the action first per-
     forms matching which may influence numeric variable references in
     the argument.  this is can be seen as a layering violation, and the
     variable draft should state explicitly whether such extensions are
     possible.

e)   the numeric variables are causing many headaches since they may
     change spontaneously when running tests or even _during_ actions.

(Continue reading)

ned.freed | 3 Aug 2004 19:51

Re: variables extension redux


> On fre, 2004-07-30 at 16:31 +0100, Alexey Melnikov wrote:
> > If this helps to get Sieve variables published (I am being selfish here,
> > of course ), than I agree.

> I'm sorry, but I've lost track.  what should be done about it?  there
> are some open issues in it, but they don't seem very hard problems,
> really.  I apologise if I have left out criticisms, it is not
> intentional, my memory isn't so good.

> === excerpt ===
> 0.3.  Open Issues

> b)   this extension is particularily useful if fileinto creates new
>      folders on demand.  [SIEVE] doesn't prohibit this, and currently
>      some implementations will create new folders automatically, others
>      won't.

> [out of scope, an explicit :createfolder for fileinto should be a
> separate extension.  this can be closed.]

Agreed.

> d)   the EDITHEADER draft includes an action that needs the unexpanded
>      string to be passed to the procedure, since the action first per-
>      forms matching which may influence numeric variable references in
>      the argument.  this is can be seen as a layering violation, and the
>      variable draft should state explicitly whether such extensions are
>      possible.

(Continue reading)

Kjetil Torgrim Homme | 4 Aug 2004 10:13

Picon

Picon

Re: variables extension redux


On tir, 2004-08-03 at 10:51 -0700, ned.freed <at> mrochek.com wrote:
> > d)   the EDITHEADER draft includes an action that needs the unexpanded
> >      string to be passed to the procedure, since the action first per-
> >      forms matching which may influence numeric variable references in
> >      the argument.  this is can be seen as a layering violation, and the
> >      variable draft should state explicitly whether such extensions are
> >      possible.
> 
> Vacation also needs access to the unexpanded strings for its internal hash
> computations. This means that implementations need to allow for argument
> evaluation to be done in two steps, first get the argument, then expand it.
> Given that you have to allow for this anyway I don't see a problem with letting
> future extensions do this sort of thing explicitly.

"vacation" is a good example.  perhaps a implementor's hint is off-topic
for the draft, but I suggest adding this to the end of 3 (just after the
next excerpt), before 3.1.

        Tests or actions in future extensions may want to access the
        unexpanded version of the string argument and do the expansion
        after, e.g., setting variables in its namespace.  The design of
        the implementation should allow this.

or more tersely:

        Future extensions may require access to the unexpanded version
        of the string argument.

(it's a given the implementation provides an internal function for

(Continue reading)

ned.freed | 4 Aug 2004 17:50

Re: variables extension redux


> On tir, 2004-08-03 at 10:51 -0700, ned.freed <at> mrochek.com wrote:
> > > d)   the EDITHEADER draft includes an action that needs the unexpanded
> > >      string to be passed to the procedure, since the action first per-
> > >      forms matching which may influence numeric variable references in
> > >      the argument.  this is can be seen as a layering violation, and the
> > >      variable draft should state explicitly whether such extensions are
> > >      possible.
> >
> > Vacation also needs access to the unexpanded strings for its internal hash
> > computations. This means that implementations need to allow for argument
> > evaluation to be done in two steps, first get the argument, then expand it.
> > Given that you have to allow for this anyway I don't see a problem with letting
> > future extensions do this sort of thing explicitly.

> "vacation" is a good example.  perhaps a implementor's hint is off-topic
> for the draft, but I suggest adding this to the end of 3 (just after the
> next excerpt), before 3.1.

>         Tests or actions in future extensions may want to access the
>         unexpanded version of the string argument and do the expansion
>         after, e.g., setting variables in its namespace.  The design of
>         the implementation should allow this.

> or more tersely:

>         Future extensions may require access to the unexpanded version
>         of the string argument.

> (it's a given the implementation provides an internal function for

(Continue reading)

Kjetil Torgrim Homme | 5 Aug 2004 16:04

Picon

Picon

Re: variables extension redux


thank you for your feedback, Ned, I've updated my copy of the draft, and
closed all the open issues.

I'd like to bring up a new open issue, though:

6.  Implementation Limits

   An implementation of this draft MUST support at least 128 distinct
   variables.  The supported length of variable names MUST be at least
   32 characters.  Each variable MUST be able to hold at least 4000
   characters.  Attempts to set the variable to a value larger than what
   the implementation supports MUST be treated as an error.

   Numeric variables ${1} through ${9} MUST be supported.  Referencing
   higher indices than is supported is a syntax error which MUST be dis-
   covered at compile-time.  If the string matching a wildcard or a
   regex group operator exceeds the maximum variable size, the implemen-
   tation SHOULD truncate it and MUST NOT treat it as an error.

I'm not entirely happy with this since in a minimal implementaion it
makes

   if header :matches "Subject" "*" {
      set "subject" "I'm gone (was: ${1})";
   }

a run-time error whenever Subject is more than 4000 characters long:  $1
is truncated, but the expanded string is too long.  the result is Sieve
aborting, and the e-mail is implicitly kept.  if the desired action is a

(Continue reading)

ned.freed | 5 Aug 2004 16:34

Re: variables extension redux


> thank you for your feedback, Ned, I've updated my copy of the draft, and
> closed all the open issues.

> I'd like to bring up a new open issue, though:

> 6.  Implementation Limits

>    An implementation of this draft MUST support at least 128 distinct
>    variables.  The supported length of variable names MUST be at least
>    32 characters.  Each variable MUST be able to hold at least 4000
>    characters.  Attempts to set the variable to a value larger than what
>    the implementation supports MUST be treated as an error.

>    Numeric variables ${1} through ${9} MUST be supported.  Referencing
>    higher indices than is supported is a syntax error which MUST be dis-
>    covered at compile-time.  If the string matching a wildcard or a
>    regex group operator exceeds the maximum variable size, the implemen-
>    tation SHOULD truncate it and MUST NOT treat it as an error.

> I'm not entirely happy with this since in a minimal implementaion it
> makes

>    if header :matches "Subject" "*" {
>       set "subject" "I'm gone (was: ${1})";
>    }

> a run-time error whenever Subject is more than 4000 characters long:  $1
> is truncated, but the expanded string is too long.  the result is Sieve
> aborting, and the e-mail is implicitly kept.  if the desired action is a

(Continue reading)

Kjetil Torgrim Homme | 31 Jul 2004 21:34

Picon

Picon

Re: variables extension redux

On lør, 2004-07-31 at 19:21 +0200, Kjetil Torgrim Homme wrote:

>      a related question is what happens when a match fails.  the draft
>      currently says that the numeric variables are reset, but this may
>      be inconvenient.
> 
> [this is irrelevant if we use SETMATCH]

I wasn't thinking clearly when I wrote that, sorry ...  the SETMATCH
doesn't remove the need for implicit state, it just limits the access to
that implicit state to places in the grammar which allow actions.

a contrived example:

  if allof (address :matches "To" "ietf-* <at> *",
            not address :matches "To" "ietf-mta-filters <at> *") { ...

consider a To containing "ietf-mta-wars".  the first test is a success,
the second is not.  the implicit state is thus cleared, and we can't get
at the domain even if the allof test is successful.  neither can we get
at the "mta-wars" part.  in this case, reversing the ordering of the
tests solves the problem, so it's not hard to work around it.

on the other hand: in Perl, an unsuccessful match does not change the
implicit state.  I'm not aware of any other languages with implicit
state in this manner.  in the origin of this, sed, the scope of \1 is
restricted to the substitute operation it's used in.

one useful recipe if state is _not_ reset, is testing for fallback:

(Continue reading)

Return

Return to gmane.ietf.mta-filters.

Search Archive

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane