Subject: Filtering and IMAP

From: Forrest Aldrich <[email-masked]>
Date: Mon, 1 May 1995 13:35:48 -0400 (EDT)

How does one initiate filtering and such (as provided with procmail) if they
use the IMAP protocol?

---

From: Nancy McGough <[email-masked]>
Date: 1 May 1995 14:09:45 -0701

>How does one initiate filtering and such (as provided with procmail) if they

Do you have shell access to the machine that stores your mail folders?
If so, just set things up in the usual way and the filtered folders
will show up in your Pine folder list.  I've set a lot of people up
with PC-Pine to IMAP to access procmail-filtered folders on a Unix host.
-- 
 /\_/\                  @..@    Please make sure your host gets the  /\_/\
( o.o ) Nancy McGough  (----)   new humanities.* newsgroups. Info   ( o.o )
 > ^ <  Infinite Ink  ( >__< )  is at http://www.jazzie.com/ii/      > ~ <

---

From: David L Miller <[email-masked]>
Date: Tue, 2 May 1995 08:55:07 -0700 (PDT)

Filtering on a black-box IMAP server (no shell access) is currently an
unsolved problem.  We have implemented a partial solution in our tmail
delivery agent by supporting "user+folder" addressing, e.g. if you send a
message to [email-masked] it will be delivered straight to my
"pine" incoming folder.... 

|\ |  |\/|  David L. Miller    [email-masked]  (206) 685-6240
|/ |_ |  |  Software Engineer, Pine Development Team   (206) 685-4045 (FAX)
University of Washington, Networks & Distributed Computing, JE-20
4545 15th Ave NE, Seattle WA 98105, USA

On 1 May 1995, Nancy McGough wrote:

> Date: 1 May 1995 14:09:45 -0701
> From: Nancy McGough <[email-masked]>
> To: [email-masked]
> Subject: Re: Filtering and IMAP
>

---

From: [email-masked] (Trey Harris)
Date: 1 May 1995 22:05:43 GMT

In article <[email-masked]>,
>How does one initiate filtering and such (as provided with procmail) if they

Three ways that I know of:

1. Do not "seal" your IMAP server, i.e. run your IMAP server as an
   ordinary machine capable of serving user logins.  Then IMAP won't
   even come into it because your mail transport agent will notice the
   .forward file in the user's home directory and deliver to the
   program (such as procmail).

2. Use Pine to do aggregate-command-set selection using the semicolon
   key followed by the (A)pply key.  Many of the things the average
   procmail user wants to do can be implemented in this way.  However,
   it must be done by hand every time you log in (or you could alias a
   pine command that had initial keystrokes, but that would be
   complicated).

3. If you must seal your IMAP server (and to me, at least, this is one
   of the primary reasons for using IMAP) and the Pine
   aggregate-command-set isn't powerful enough, then write a program
   which connects to the IMAP daemon, does the appropriate searches,
   and takes action on the messages returned.

There may be other ways, too.
-- 
Trey Harris                              http://sunsite.unc.edu/harris
  System Administrator, Project Isis, Office of Information Technology
                       The University of North Carolina at Chapel Hill

---

From: [email-masked] (Jason Haar)
Date: 3 May 1995 16:54:10 GMT

> "pine" incoming folder.... 

To me IMAP seems so close to allowing this...

IMAP allows you to open non-mail folders, so couldn't there be some way of 
getting IMAP to edit files like .forward and .procmailrc? 

Actually, this reminds me of an earlier post I made asking if IMAP could 
be used to store a central .pinerc file on the IMAP server instead of the 
client - same principle - just opened up a bit further... Local filters 
like procmail would be more efficient than getting the mailer to go 
through filter hoops...

That would be most excellent - but it would be moving away from the 
simple model...

 --

Cheers,

Jason
+------------------------------+------------------------------------------+
| Jason Haar, European SysAdmin   Phone: + 44 (256) 790577                |
| Motorola Cellular Subscriber      Fax: + 44 (256) 790519                |
| Basingstoke, Hampshire                                                  |
| RG21 1PL,  ENGLAND           Internet: [email-masked] |
+------------------------------+------------------------------------------+

---

From: John Gardiner Myers <[email-masked]>
Date: Wed, 3 May 1995 10:44:35 -0400

> There may be other ways, too.

4. Teach your delivery service to do filtering based on information
   the user loaded into some directory service (such as LDAP).

-- 
_.John G. Myers		Internet: [email-masked]
			LoseNet:  ...!seismo!ihnp4!wiscvm.wisc.edu!give!up

---

From: Terry Gray <[email-masked]>
Date: Thu, 4 May 1995 13:52:00 -0700 (PDT)

> How does one initiate filtering and such (as provided with procmail) if they

There have been several suggestions made so far.  I'm going to recap some 
of them and add several possibities that haven't been mentioned.  I will 
not mention suggestions that involve firing up a Mail User Agent to act 
on the mail store, as I think most people want filtering to be done by
the delivery agent at "message delivery time", rather than by an MUA at 
"message reading time"...

1. Run IMAP on an "unsealed" system where logins are permitted and 
   procmail or filter or deliver can be used in the normal way. <Harris>
2. Run IMAP on a "semi-sealed" system which shares some state with 
   systems where logins are permitted.  One scenario: the IMAP server
   does not permit user logins, but imports user home directories and the
   delivery agent respects any .forward entries it finds.
3. Teach your delivery service to do filtering based on information
   the user loaded into some directory service (such as LDAP).  <Myers>
4. Mailbots.  It is possible to construct a service for manipulating
   a procmail (etc.) rule base via email messages.  The advantage is
   being able to use any mail client to, for example, set a vacation 
   msg.  A key requirement is for the requestor to be authenticated,
   which could be done in any of several ways, e.g. PGP, or some form of 
   "two-party authentication" wherein a "magic cookie" is sent to the 
   user's mailbox by the mailbot engine and is used in subsequent 
   transactions for authentication.  In its simplest form, this scheme
   would have a very limited set of services (e.g. vacation setup) and
   a correspondingly simple command syntax (and/or a task-specific set of
   mailbot addresses.)  One can imagine a more general-purpose rule 
   definition language being transmitted to the delivery filter via this 
   kind of mechanism.  (Laurence Lundblade at Virginia Tech has been working
   on such a language, which he has dubbed "Sift-TCL".)
5. WWW forms.  WWW forms are being used for *everything* these days, even 
   session-oriented transaction sequences that require authentication.
   I can't see any reason why someone couldn't solve the remote procmail
   configuration problem using this approach.

On 3 May 1995, Jason Haar asked why you couldn't edit procmail config
files via IMAP, and why it couldn't be used to store Pine config files.

The answer for both questions is that a case can be made for having 
several simple protocols for different tasks, rather than one "does 
everything" protocol.

In the case of remote access to pine configuration data, we expect to use 
the IMAP companion protocol, IMSP, which is being developed at CMU.

In the case of procmail configuration data, any of the options listed
above seem plausible.  In principle, since IMAP supports an APPEND
operation, one could write arbitrary data to a file on the server and
invent an agent that could do something useful with it, but even though I
also like to reuse existing mechanism rather than inventing new, I'm not
convinced that's the best approach to this particular problem. 

-teg

---

From: David L Miller <[email-masked]>
Date: Thu, 4 May 1995 14:07:39 -0700 (PDT)

One of the reasons that the file driver in the UW IMAP server is Read-Only
is that allowing an IMAP client to write a free-format flat file would
open up a pandora's box of security problems.  For example, if Pine could
write a .forward file in someone's home directory, what would prevent it
from writing a .cshrc file or .rhosts file?  At least with a mailbox
format file you are not too likely to be able to do that kind of damage. 
Solving that and other problems would take IMAPd far down a path that we
are not eager to explore in a "message access" service... 

On 3 May 1995, Jason Haar wrote:

> Date: 3 May 1995 16:54:10 GMT
> From: Jason Haar <[email-masked]>

---

From: [email-masked] (Trey Harris)
Date: 5 May 1995 15:41:09 GMT

In article <[email-masked]>,
>getting IMAP to edit files like .forward and .procmailrc? 

No, IMAP does not allow that, in general.

>That would be most excellent - but it would be moving away from the 

Away from the simple model, yes, but towards where IMAP4 and IMSP are 
going in the future.

IMSP allows the saving of configuration variables, etc., in the 
centralized repository.  It also allows the IMSP server to tell a client 
where its IMAP mailbox is, which means that if you want to run twenty 
IMAP servers, your users don't need to know on which their mailbox resides.

For more, check out the Cyrus IMAP4 server page, which has links to the 
IMAP4, IMAP4 authentication methods, and IMSP RFCs.

It's at http://andrew2.andrew.cmu.edu/cyrus/cyrus.
-- 
Trey Harris                              http://sunsite.unc.edu/harris
  System Administrator, Project Isis, Office of Information Technology
                       The University of North Carolina at Chapel Hill