[Top] [All Lists]

is it allowed to discuss client side filtering here?

2003-03-18 13:47:47

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 
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: lyndon(_at_)esys(_dot_)ca
(whose comments are cited below with "    LN> "),
had this to say in article 
concerning the subject of Re: MTA Filters BOF request, LA IETF; Proposed 

    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?


<Prev in Thread] Current Thread [Next in Thread>