ietf-mta-filters
[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 
<9701120106(_dot_)AA25172(_at_)lever(_dot_)dr(_dot_)lucent(_dot_)com>
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 
<SIMEON(_dot_)9801121619(_dot_)B5724(_at_)lautrec(_dot_)esys(_dot_)ca>
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

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