Subject: lunch/bar bof for mta-filters?

From: Tony Hansen <[email-masked]>
Date: Fri, 30 Jul 2004 01:33:34 -0400

Any interest in having a lunch bof or bar bof in San Diego to discuss 
the various sieve extensions that are currently extant?

I'd like to suggest meeting at lunchtime on Wednesday or Thursday.

	Tony Hansen
	[email-masked]

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 30 Jul 2004 14:48:44 +0100

> I'd like to suggest meeting at lunchtime on Wednesday or Thursday. 

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

Alexey

---

From: [email-masked]
Date: Fri, 30 Jul 2004 07:26:32 -0700 (PDT)

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

Wednesday lunch works for me.

				Ned

---

From: [email-masked]
Date: Fri, 30 Jul 2004 08:18:20 -0700 (PDT)

> Hi [email-masked],

> --On Friday, July 30, 2004 7:26 AM -0700 [email-masked] 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?

				Ned

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 30 Jul 2004 16:31:54 +0100

> 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

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 30 Jul 2004 11:56:43 -0400

Hi ned,

> 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 
can be used for additional filtering). Having an official WG may help with 
determining that.

-- 
Cyrus Daboo

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 30 Jul 2004 17:42:44 +0200

> 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

---

From: Rob Siemborski <[email-masked]>
Date: Fri, 30 Jul 2004 11:58:30 -0400 (EDT)

> 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 * [email-masked] * 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+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y?
------END GEEK CODE BLOCK-----

---

From: [email-masked]
Date: Fri, 30 Jul 2004 09:14:55 -0700 (PDT)

> Other extensions that have wide deployment right now also ought to be part

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?

> draft so we ought to be OK.

The problematic one is going to be ACAP. I would plan to ask for an exception
for that one - it is to the comparator registry, and it can be argued that the
registry is really an IANA/BCP sort of thing even though it appears in a
proposed standard RFC. I do think the registry reference is normative, however
- you need to know what the comparators do in order to build a sieve
interpreter.

> can be used for additional filtering). Having an official WG may help with

Agreed, although the MARID group has a number of really serious problems to
contend with that may make it difficult to get their attention no matter what
(and perhaps rightly so). I mean, when Richard Stallman is posting to the list
(and being told by the chairs that the discussion isn't approrpiate), you know
there's a situation.

				Ned

P.S. I'm going to try to have some review comments in hand by the Wed meeting
on the various drafts. Hopefully others can do the same and we can collect an
open issues/corrections list.

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 30 Jul 2004 12:53:46 -0400

--On Friday, July 30, 2004 9:14 AM -0700 [email-masked] 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.
>> >
>> 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.
>

Agreed.

> Do you think the managesieve stuff would also be appropriate?

I think there are enough implementations (both server and client) around to 
warrant this. Perhaps if others are considering doing implementations they 
could let us known as that might tip the balance for adding it to any WG 
charter. Is suspect there really isn't a lot of work involved in 
progressing the draft.

>> 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.
>
> The problematic one is going to be ACAP. I would plan to ask for an
> exception for that one - it is to the comparator registry, and it can be
> argued that the registry is really an IANA/BCP sort of thing even though
> it appears in a proposed standard RFC. I do think the registry reference
> is normative, however - you need to know what the comparators do in order
> to build a sieve interpreter.

Remember that ACAP failed to actually (officially) create the registry. 
Chris Newman's i18n-comparator draft is supposed to do that:

<http://www.ietf.org/internet-drafts/draft-newman-i18n-comparator-02.txt>

So perhaps that is what we have to end up referencing. That does have 
normative references to stringprep and nameprep amoungst others. Sadly this 
might be what delays SIEVE getting to draft...

> P.S. I'm going to try to have some review comments in hand by the Wed
> meeting on the various drafts. Hopefully others can do the same and we
> can collect an open issues/corrections list.

I'll try to do the same - should be time enough on the flight over...

-- 
Cyrus Daboo

---

From: Jutta Degener <[email-masked]>
Date: Fri, 30 Jul 2004 10:30:33 -0700

> Wednesday lunch works for me.

I'll be there all week, and Wednesday lunch works as well.
(And aye on the working group.)

Jutta <[email-masked]>

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Sat, 31 Jul 2004 19:21:39 +0200

> 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.
     an alternative approach is SETMATCH ["var1", "var2", "var3"] which
     stores the first three match components into the listed variables.
     (an empty string as a variable name means skip storing that match.)
     this approach makes REPLACEHEADER less powerful.

[this is a big change to the draft, but I think it makes the semantics
clearer and reduces the chances of pitfalls.  the REPLACEHEADER magic
was too magic, IMHO (it was removed from the draft anyway, but someone
else may want something similar in the future)]

     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]
=== ends ===

I can submit a "new" draft to refresh the expiry in a couple of days,
but if we can get these issues resolved first, that would be great.

-- 
Kjetil T.

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Sat, 31 Jul 2004 21:34:54 +0200

> [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-*@*",
            not address :matches "To" "ietf-mta-filters@*") { ...

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:

  if match-test1 { do-stuff1 }
  if match-test2 { do-stuff2 }
  if string "${0}" "0" {
     # this is true if neither match-test1 nor match-test2 were true.
     # sometimes match-test1 and match-test2 aren't mutually exclusive,
     # so if ... {} else if ... {} else ... {} isn't appropriate.
  }

of course, the programmer can use an explicit flag variable in each of
do-stuff1 and do-stuff2 instead, but I believe this will make the idiom
harder to recognise for a GUI editor.

getting back to SETMATCH, it makes accessing ${0} inconvenient to say
the least, so the above hack can't be used.  (the first match may well
be a zero-length string.)

it also requires the following example to be rewritten into nested if
tests:

  if allof (header :matches "List-ID" "*<[email-masked]>*",
            address :localpart "To" "${2}") {
      ...
  }

it becomes:

  if header :matches "List-ID" "*<[email-masked]>*" {
	setmatch ["", "listname"]
        if address :localpart "To" "${listname} {
             ...
        }
  }

I don't see this as a bad thing, really.

-- 
Kjetil T.

Subject: Re: variables extension redux
From: Kjetil Torgrim Homme <[email-masked]>
To: [email-masked]
Date: Sat, 31 Jul 2004 21:34:54 +0200
Sender: [email-masked]

> [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-*@*",
            not address :matches "To" "ietf-mta-filters@*") { ...

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:

  if match-test1 { do-stuff1 }
  if match-test2 { do-stuff2 }
  if string "${0}" "0" {
     # this is true if neither match-test1 nor match-test2 were true.
     # sometimes match-test1 and match-test2 aren't mutually exclusive,
     # so if ... {} else if ... {} else ... {} isn't appropriate.
  }

of course, the programmer can use an explicit flag variable in each of
do-stuff1 and do-stuff2 instead, but I believe this will make the idiom
harder to recognise for a GUI editor.

getting back to SETMATCH, it makes accessing ${0} inconvenient to say
the least, so the above hack can't be used.  (the first match may well
be a zero-length string.)

it also requires the following example to be rewritten into nested if
tests:

  if allof (header :matches "List-ID" "*<[email-masked]>*",
            address :localpart "To" "${2}") {
      ...
  }

it becomes:

  if header :matches "List-ID" "*<[email-masked]>*" {
	setmatch ["", "listname"]
        if address :localpart "To" "${listname} {
             ...
        }
  }

I don't see this as a bad thing, really.

-- 
Kjetil T.

Subject: variables extension redux
From: Kjetil Torgrim Homme <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]
Date: Sat, 31 Jul 2004 19:21:39 +0200
Sender: [email-masked]

=== excerpt ===
0.3.  Open Issues

-- 
Kjetil T.

From: "Mark E. Mallett" <[email-masked]>
Date: Sat, 31 Jul 2004 09:45:17 -0400
To: Cyrus Daboo <[email-masked]>
Cc: [email-masked]
Subject: Re: lunch/bar bof for mta-filters?
Sender: [email-masked]

[Dang, this might have been worth going to San Diego for]

On Fri, Jul 30, 2004 at 12:00:32PM -0400, Cyrus Daboo wrote:
> 
> To that end it might be useful to tabulate the number of client/server 
> implementations of the existing draft extensions, so that we can get an 
> idea of which ones need to be worked on sooner rather than later. I would 
> be happy to add that info to my informal draft status list if folks want to 
> send me that information privately or on the list. All I would need to know 
> is what extension 'require' keyword is used and whether its used by a sieve 
> server (script parser) or client (script generator).

There's also Matthew Elvey's page at:

  http://wiki.fastmail.fm/wiki/index.php/SieveExtensionsSupportMatrix

mm

Date: Fri, 30 Jul 2004 13:46:38 -0400
From: Cyrus Daboo <[email-masked]>
To: [email-masked]
cc: Ned Freed <[email-masked]>
Subject: Working Group
Sender: [email-masked]

It does appear that there is a lot of support for having a working group 
for SIEVE, and I think we should move forward and contact the ADs and see 
what they have to say. Perhaps we should invite them to the lunch meeting, 
or maybe this issue could be brought up at the Apps area meeting? I suspect 
Ned can suggest the best way to proceed...

-- 
Cyrus Daboo

Date: Fri, 30 Jul 2004 10:30:33 -0700
From: Jutta Degener <[email-masked]>
To: [email-masked]
Cc: Alexey Melnikov <[email-masked]>, Tony Hansen <[email-masked]>, [email-masked]
Subject: Re: lunch/bar bof for mta-filters?
Sender: [email-masked]

Date: Fri, 30 Jul 2004 09:59:45 -0700 (PDT)
From: [email-masked]
Subject: Re: Drafts and status
To: Rob Siemborski <[email-masked]>
Cc: Cyrus Daboo <[email-masked]>, IETF MTA Filters List <[email-masked]>
Sender: [email-masked]

> On Fri, 30 Jul 2004, Cyrus Daboo wrote:

> > draft-martin-managesieve-04.txt
> >
> >       Draft has EXPIRED. Ned (then AD) sent comments to the list on
> >       12-Nov-2003. These have yet to be addressed. There was also an
> >       issue with interaction with include extension. I think its up
> >       to the CMU folks to move this forward...

> I've sent email to Tim several times asking him to either fix the draft or
> send me the source so that I can take it over, and neither has happened.

> Is there a fast way to convert an ID into nroff or XML source?

Not that I know of. I've always done it manually, usually while sitting
in airport departure lounges.

				Ned

Date: Fri, 30 Jul 2004 12:53:46 -0400
From: Cyrus Daboo <[email-masked]>
To: [email-masked]
cc: [email-masked]
Subject: Re: lunch/bar bof for mta-filters?
Sender: [email-masked]

Agreed.

-- 
Cyrus Daboo

Date: Fri, 30 Jul 2004 21:56:52 +0530
From: Madan Ganesh Velayudham <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Cc: IETF MTA Filters List <[email-masked]>
Subject: Re: Drafts and status
Sender: [email-masked]

Thanks Cyrus,

 > draft-madanganeshv-sieve-remove-attach-00.txt
 >
 >        Draft has EXPIRED. Some comments on the list back in February. 
This
 >        too may have overlap with 'mime' and 'loop' extensions.
 >
 > draft-madanganeshv-sieve-stat-01.txt
 >
 >        Draft still active. Some comments on the list back in February.
 >

I will be not attending this IETF. Will update it and discuss thru Jabber.

Thanks
MG

-- 
            Madan Ganesh Velayudham  +91 80 2205 3108
-------------------------------------------------------------
Nothing in life is to be feared.  It is only to be understood.

Date: Fri, 30 Jul 2004 09:14:55 -0700 (PDT)
From: [email-masked]
Subject: Re: lunch/bar bof for mta-filters?
To: Cyrus Daboo <[email-masked]>
Cc: [email-masked], Alexey Melnikov <[email-masked]>, Tony Hansen <[email-masked]>, [email-masked]
Sender: [email-masked]

				Ned

Date: Fri, 30 Jul 2004 12:01:28 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Cyrus Daboo <[email-masked]>
cc: IETF MTA Filters List <[email-masked]>
Subject: Re: Drafts and status
Sender: [email-masked]

On Fri, 30 Jul 2004, Cyrus Daboo wrote:

> draft-martin-managesieve-04.txt
>
>       Draft has EXPIRED. Ned (then AD) sent comments to the list on
>       12-Nov-2003. These have yet to be addressed. There was also an
>       issue with interaction with include extension. I think its up
>       to the CMU folks to move this forward...

I've sent email to Tim several times asking him to either fix the draft or 
send me the source so that I can take it over, and neither has happened.

Is there a fast way to convert an ID into nroff or XML source?

-Rob

-----BEGIN GEEK CODE BLOCK----
Version: 3.12
------END GEEK CODE BLOCK-----

Date: Fri, 30 Jul 2004 17:01:13 +0100
From: Alexey Melnikov <[email-masked]>
To: Cyrus Daboo <[email-masked]>
CC: IETF MTA Filters List <[email-masked]>
Subject: Re: Drafts and status
Sender: [email-masked]

Cyrus Daboo wrote:

> Hi folks,
> Here is a list of current SIEVE drafts and their status as far as I 
> can tell. Please let me know if I have missed any or if any of the 
> information below is incorrect.
>
> draft-melnikov-sieve-imapflags-06.txt
>
>        Open issues remain. Rob sent message to list 24-Feb-2004 proposing
>        some changes. No further discussion. I believe there are 
> several implementations
>        of this.

This draft depends on Sieve variable, which is the major issue.

Date: Fri, 30 Jul 2004 12:00:32 -0400
From: Cyrus Daboo <[email-masked]>
To: [email-masked]
Subject: Re: lunch/bar bof for mta-filters?
Sender: [email-masked]

Hi Simon,

--On Friday, July 30, 2004 5:42 PM +0200 Simon Josefsson <[email-masked]> 
wrote:

> Having done multiple implementations of it, I have some
> vested interest in it.
>

To that end it might be useful to tabulate the number of client/server 
implementations of the existing draft extensions, so that we can get an 
idea of which ones need to be worked on sooner rather than later. I would 
be happy to add that info to my informal draft status list if folks want to 
send me that information privately or on the list. All I would need to know 
is what extension 'require' keyword is used and whether its used by a sieve 
server (script parser) or client (script generator).

-- 
Cyrus Daboo

Date: Fri, 30 Jul 2004 11:58:30 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: [email-masked]
cc: Cyrus Daboo <[email-masked]>, Alexey Melnikov <[email-masked]>, Tony Hansen <[email-masked]>, [email-masked]
Subject: Re: lunch/bar bof for mta-filters?
Sender: [email-masked]

-Rob

-----BEGIN GEEK CODE BLOCK----
Version: 3.12
------END GEEK CODE BLOCK-----

Date: Fri, 30 Jul 2004 11:56:43 -0400
From: Cyrus Daboo <[email-masked]>
To: [email-masked]
cc: Alexey Melnikov <[email-masked]>, Tony Hansen <[email-masked]>, [email-masked]
Subject: Re: lunch/bar bof for mta-filters?
Sender: [email-masked]

Hi ned,

-- 
Cyrus Daboo

To: [email-masked]
From: Simon Josefsson <[email-masked]>
Subject: Re: lunch/bar bof for mta-filters?
Date: Fri, 30 Jul 2004 17:42:44 +0200
Lines: 23
Cancel-Lock: sha1:YUvasSk+n7DAggvPZWjRUt9Rp/I=
Sender: [email-masked]

Thanks,
Simon

Date: Fri, 30 Jul 2004 11:39:17 -0400
From: Cyrus Daboo <[email-masked]>
To: IETF MTA Filters List <[email-masked]>
Subject: Drafts and status
Sender: [email-masked]

Hi folks,
Here is a list of current SIEVE drafts and their status as far as I can 
tell. Please let me know if I have missed any or if any of the information 
below is incorrect.

draft-melnikov-sieve-imapflags-06.txt

        Open issues remain. Rob sent message to list 24-Feb-2004 proposing
        some changes. No further discussion. I believe there are several 
implementations
        of this.

draft-showalter-sieve-vacation-05.txt

        Draft is in 'DEAD' state in  ID-tracker. This needs to be addressed.
        Ned (then AD) sent comments to the list on 25-Jan-2004. These have
        yet to be addressed. There is really not much that needs doing to
        this so we ought to get it out soon. There are many implementations 
of this around.

draft-murchison-sieve-regex-07.txt

        Draft has EXPIRED. Last set of open issues were to do with i18n and
        back references. There are several implementations of this around.

draft-martin-managesieve-04.txt

        Draft has EXPIRED. Ned (then AD) sent comments to the list on
        12-Nov-2003. These have yet to be addressed. There was also an
        issue with interaction with include extension. I think its up
        to the CMU folks to move this forward...

draft-martin-sieve-notify-02.txt

        Draft has EXPIRED. No recent activity on the list.

draft-degener-sieve-body-02.txt

        Draft still active. There seem to be several implementations of 
this around.

draft-daboo-sieve-include-02.txt

        Draft still active. Recent update published. I know of one 
implementation to date.

draft-homme-sieve-variables-02.txt

        Draft has EXPIRED. No recent activity on the list.

draft-degener-sieve-multiscript-01.txt

        Draft has EXPIRED. No recent activity on the list.

draft-degener-sieve-editheader-01.txt

        Draft still active. Some comments on the list back in January.

draft-degener-sieve-copy-03.txt

        Draft still active. Recent update published. Ned (then AD) sent
        comments to the list in January. He indicated the draft was very
        close to being done.

draft-elvey-refuse-sieve-02.txt

        Draft still active. Some comments on the list back in May.

draft-daboo-sieve-mime-00.txt

        Draft still active. Several comments after initial publication in
        March. Possible overlap with Tony's 'loop' extension. More
        discussion required.

draft-madanganeshv-sieve-remove-attach-00.txt

        Draft has EXPIRED. Some comments on the list back in February. This
        too may have overlap with 'mime' and 'loop' extensions.

draft-madanganeshv-sieve-stat-01.txt

        Draft still active. Some comments on the list back in February.

draft-hansen-sieve-loop-00.txt

        Draft recently posted. Recent discussion about overlap with 'mime'
        extension. More discussion required.

-- 
Cyrus Daboo

Date: Fri, 30 Jul 2004 16:31:54 +0100
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: lunch/bar bof for mta-filters?
Sender: [email-masked]

Alexey

Date: Fri, 30 Jul 2004 08:18:20 -0700 (PDT)
From: [email-masked]
Subject: Re: lunch/bar bof for mta-filters?
To: Cyrus Daboo <[email-masked]>
Cc: [email-masked], Alexey Melnikov <[email-masked]>, Tony Hansen <[email-masked]>, [email-masked]
Sender: [email-masked]

				Ned

Date: Fri, 30 Jul 2004 11:02:32 -0400
From: Cyrus Daboo <[email-masked]>
To: [email-masked]
Subject: Re: Vacation draft
Sender: [email-masked]

Hi Michael,

--On Friday, July 30, 2004 11:36 AM +0200 Michael Haardt 
<[email-masked]> wrote:

> As I noticed, the draft ist expired.  Any plans to bring it back?

Unfortunately this document appears to be in a sorry state:

<https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=3116&rfc_flag=0>

We need to get this published. If Tim is unable to do the updates then we 
need to assign a new author and move it forward asap. I would be willing to 
do that if needs be.

-- 
Cyrus Daboo

Date: Fri, 30 Jul 2004 11:02:11 -0400
From: Cyrus Daboo <[email-masked]>
To: [email-masked]
Subject: Re: lunch/bar bof for mta-filters?
Sender: [email-masked]

-- 
Cyrus Daboo

Date: Fri, 30 Jul 2004 07:26:32 -0700 (PDT)
From: [email-masked]
Subject: Re: lunch/bar bof for mta-filters?
To: Alexey Melnikov <[email-masked]>
Cc: Tony Hansen <[email-masked]>, [email-masked]
Sender: [email-masked]

				Ned

Date: Fri, 30 Jul 2004 14:48:44 +0100
From: Alexey Melnikov <[email-masked]>
To: Tony Hansen <[email-masked]>
CC: [email-masked]
Subject: Re: lunch/bar bof for mta-filters?
Sender: [email-masked]

Alexey

Date: Fri, 30 Jul 2004 09:49:19 -0400
From: Tony Hansen <[email-masked]>
To: Nigel Swinson <[email-masked]>
CC: [email-masked]
Subject: Re: I-D ACTION:draft-hansen-sieve-loop-00.txt]
Sender: [email-masked]

Nigel Swinson wrote:

> Hi Tony,
> 
> Just read your new I-Draft and it seems to be solving some of the 
> same problems that the draft-daboo-sieve-mime-00.txt draft is trying
> to solve, so it seems like the two should probably be worked on
> together.
 >
 > But I made an alternative proposal in response that seemed to have a
 > lot of support although was never written up into a new draft. You
 > can read my response here and follow the replies:
 > http://www.imc.org/ietf-mta-filters/mail-archive/msg02238.html

I agree - there is some overlap between our drafts, as well as with your 
ideas. I'll have to review the thread you pointed me to.

	Tony Hansen
	[email-masked]

From: "Nigel Swinson" <[email-masked]>
To: "Tony Hansen" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: I-D ACTION:draft-hansen-sieve-loop-00.txt]
Date: Fri, 30 Jul 2004 12:11:41 +0100
Sender: [email-masked]

Hi Tony,

Just read your new I-Draft and it seems to be solving some of the same problems that the draft-daboo-sieve-mime-00.txt draft is trying to solve, so it seems like the two should probably be worked on together.  

The original draft is here:  http://www.ietf.org/internet-drafts/draft-daboo-sieve-mime-00.txt

But I made an alternative proposal in response that seemed to have a lot of support although was never written up into a new draft.  You can read my response here and follow the replies:  http://www.imc.org/ietf-mta-filters/mail-archive/msg02238.html

My proposal for a HEADER-PART tagged argument to the header does mostly the same job as your part test with :filename/:type/:subtype approach, and my :bodyparts optional argument does mostly the same job as your for.every.part loop test.  However the proposal does not include facilities for replace/delete/enclosing body parts.

I think my proposal allows significant extra message matching capabilities with less additional syntax, so I think it would be good if we could go with testing syntax more along the lines of what has already been proposed there.

Perhaps there's really two I-Drafts at play here, a written up version of my proposal for testing body parts, and then an additional one specifying the ability to replace/delete/enclose body parts which requires a "select" body part concept.  Maybe a foreach test, that is used instead of "if".  Then where you have:

   for.every.part {
       if anyof ( part :subtype :is "jpeg", part :filename :matches "*.jpg" {
           replace "Attachment removed by user filter";
       }
   }

We'd have this instead:

   foreach anyof :bodyparts (header :value :matches "Content-Type" "*/jpeg" ,
                                              header :parameter "filename" :matches "Content-Disposition" "*.jpg" ) {
       replace "Attachment removed by user filter";
   }

Cyrus, I expected you'd re-release the draft-daboo-sieve-mime-00.txt I-Draft encorporating all the feedback but don't see a version 01.txt.  Should I do this?

Nigel

To: [email-masked]
Subject: Vacation draft
From: Michael Haardt <[email-masked]>
Date: Fri, 30 Jul 2004 11:36:29 +0200
Sender: [email-masked]

I have two comments to the section security considerations:

Sending out an automated reply with "Re: " and the subject is dangerous.
Many mailing lists verify the mail address by sending a mail with a key
in the subject.  Simply replying to such a mail confirms you want to
subscribe to it.  If people use vacation, it is easy to subscribe them
to a spam list and prove that it *is* opt-in by keeping the confirmation
and throwing away the original faked subscription request.

Mail systems should be allowed to bypass the time if the database to
remember senders becomes too large.  I suggest to allow the implementation
to expire entries if the number of different senders becomes too big.
The draft could set a minimum database size. Say 100 or 1000 different
senders must be remembered, but implementations may store more.

As I noticed, the draft ist expired.  Any plans to bring it back?

Michael

Date: Fri, 30 Jul 2004 01:33:34 -0400
From: Tony Hansen <[email-masked]>
To: [email-masked]
Subject: lunch/bar bof for mta-filters?
Sender: [email-masked]

	Tony Hansen
	[email-masked]

Date: Fri, 30 Jul 2004 01:29:36 -0400
From: Tony Hansen <[email-masked]>
To: [email-masked]
Subject: [Fwd: I-D ACTION:draft-hansen-sieve-loop-00.txt]
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------070309090000060105030300
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

This was supposed to be announced to the mta-filters list by the I-D 
editor, but wasn't.

	Tony Hansen
	[email-masked]

--------------070309090000060105030300
Content-Type: message/rfc822;
 name="I-D ACTION:draft-hansen-sieve-loop-00.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="I-D ACTION:draft-hansen-sieve-loop-00.txt"

To: [email-masked]
From: [email-masked]
Date: Fri, 16 Jul 2004 16:22:22 -0400
Subject: I-D ACTION:draft-hansen-sieve-loop-00.txt
Reply-To: [email-masked]
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Sieve Extension: Bodypart Loops
	Author(s)	: T. Hansen
	Filename	: draft-hansen-sieve-loop-00.txt
	Pages		: 5
	Date		: 2004-7-16
	
The current Sieve language has no looping mechanism, a way to look at
   individual parts, or any way to manipulate those individual parts.
   This document defines extensions for each of these needs.

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

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] 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-hansen-sieve-loop-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-hansen-sieve-loop-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID: <[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-hansen-sieve-loop-00.txt

--OtherAccess
Content-Type: Message/External-body; name="draft-hansen-sieve-loop-00.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce

--NextPart--

--------------070309090000060105030300--