Subject: is it allowed to discuss client side filtering here?

From: [email-masked]
Date: Tue, 18 Mar 2003 21:47:39 +0100

Alright, I was "welcomed" with a message says this:

    [...]
    The ietf-mta-filters mailing list is used 
    to discuss and develop open standards
    for server-side filtering of mail
    in the SMTP->delivery->[mailstore/IMAP] loop.
    [...]

>>>>> On Sat, 11 Jan 97 17:06:43 PST,
>>>>> Neal McBurnett
>>>>> (whose comments are cited below with "    BOF-19961212> "),
>>>>> had this to say in article <[email-masked]>
>>>>> concerning the subject of minutes for the filtering meeting...

    BOF-19961212> Here is a copy of the minutes of the mail filtering ("anti-spam") BOF
    BOF-19961212> at the 37th IETF meeting in San Jose, Thu 12 Dec 1996.

    BOF-19961212> [...]
    BOF-19961212> - Seattle BOF did not want to consider client side filtering
    BOF-19961212> [...]

Well, if you regard the discussion of client side filtering here
as "not allowed" pls skip the rest!

>From the 1998 SIEVE draft:

    [...]
    It is designed to be independent of protocol,
    and implementable on either a mail client or mail server.  
    [...]
    This document  doesn't dictate how SIEVE interpreter
    can set [IMAP] flags. 
    In particular, SIEVE interpreter may work as an IMAP client,
    or may have direct access to the mailstore.
    [...]

>From draft-melnikov-sieve-imapflags-04.txt:

    [...]
    In particular, the SIEVE interpreter may work as an IMAP client,
    or may have direct access to the mailstore.
    [...]

I browsed through the entire archive of this mailing list ("entire-arch.txt"),
but I could not find a hint on any existing client side implementation.

Did I miss anything?

>>>>> On Mon, 12 Jan 1998 16:28:19 -0700 (MST),
>>>>> Lyndon Nerenberg
>>>>> who can be reached at: [email-masked]
>>>>> (whose comments are cited below with "    LN> "),
>>>>> had this to say in article <[email-masked]>
>>>>> concerning the subject of Re: MTA Filters BOF request, LA IETF; Proposed Charter

    LN> [...]

    LN> Procmail is a very dangerous thing in the wrong hands.
    LN> The fact that people use these dangerous tools
    LN> regardless tells me there is a requirement for the functionality.
 
    LN> [...]

    LN> Having a standard language means 
    LN> that I can reuse the same ruleset on different clients
    LN>  -- a *very* important criteria for mobile users 
    LN> who have no choice
    LN> but to use disparate UA's 
    LN> when on the road vs. being at the office.
 
    LN> [...]

Because I also could not find any client side SIEVE implementation a couple of years ago,
I started an effort then myself,
that I "modestly" ;-)     called "JHimap_utils".
A python script (making use of somebody else's IMAP interface library),
implementing a couple of utilities,
mainly for move messages from the IMAP INBOX to whatever other IMAP folder
depending on header fields.

I seriously needed such a thing then,
as my "IMAP providers" then did not let me make use of procmail.

My current "IMAP" provider provides me with a UNIX account
(they let me do IMAP with pre-authentication over ssh!),
and they let me use procmail for server side mail splitting.

Actually there would *not* be an urgent need for me
to address this issue these days,
as I got a lot of other issues to care for,
but somebody picked my software (mentioned above) up on the web
and keeps asking me questions,
so that thing awoke again somehow.

----------

What's the current status on client side mail splitting these days?

----------

I'd love to give my software a SIEVE grammar front-end,
but I somehow fear the effort.

----------

Does somebody want to discuss this?

JH

---

From: Tim Showalter <[email-masked]>
Date: Wed, 19 Mar 2003 18:43:06 -0800

>but I somehow fear the effort.
I know there would be interest in client-side Sieve filtering, but I 
don't know anyone who has really worked on it.

Personally I'd love if there was a Sieve implementation that had an 
externally procmail-like interface, and mailbox names could be file names.

Tim

---

From: Sam Roberts <[email-masked]>
Date: Wed, 19 Mar 2003 22:34:11 -0500

Checkout GNU mailutils.

It has a sieve engine, and that engine will sieve mailboxes, and you can
specify the mailboxes as:

 imap://[email-masked]
 ~/mbox
 +some_mbox

Cheers,
Sam

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 19 Mar 2003 19:45:14 -0800

Hi Tim,

--On Wednesday, March 19, 2003 6:43 PM -0800 Tim Showalter 
<[email-masked]> wrote:

| I know there would be interest in client-side Sieve filtering, but I
| don't know anyone who has really worked on it.

Our client does have both client-side filtering support and SIEVE support 
(via ManageSIEVE for uploading to the server). Right now SIEVE is not as 
'expressive' as client-side filters need to be - regex, body etc would go a 
long way to help with that.  Certainly to be effective we would need to at 
least add a 'flagtest' test for testing flag status on the message being 
processed. There are also other client-specific actions that need to be 
considered - e.g. print, save, alert etc. We would also have to define what 
things like 'discard' mean in the context of a client-side filter. That may 
well depend on when the filter is being invoked (e.g. on new mail delivery, 
on message copy, on new mail arrival etc).

I have been considering adding our own private XML rules/filter 
import/export capability which would be expressive enough to capture 
client-side filters and SIEVE. Being able to use a client-side sieve script 
that would be portable between clients would be good too.

| Personally I'd love if there was a Sieve implementation that had an
| externally procmail-like interface, and mailbox names could be file names.

-- 
Cyrus Daboo

---

From: Bill Fenner <[email-masked]>
Date: Wed, 19 Mar 2003 20:05:41 -0800

I did some work hooking up the CMU sieve implementation with the UW
imap code; I did not finish it because it turned out my IMAP server
munged all the headers that I wanted to filter on.  If someone would
find it useful and wants to finish it off I'd be happy to pass it on.

  Bill