Subject: IMAP daemon as Mail-user agent

From: [email-masked] (Trey Harris)
Date: 1 May 1995 15:38:38 GMT

(Is there a newsgroup for IMAP? A grep imap in my active file revealed
nothing...)

I am writing a Mail-user agent (MUA) for my users.  Not a generalized 
program for their everyday mailreading, but rather to do some things that 
my users are always asking me how to do and takes twenty or thirty 
commands in pine (more if they don't yet have the aggregate-command-set 
enabled).  However, since the program would have to access the mailboxes 
and change their contents, it does meet the definition of a MUA.

Since my users operate over a sealed IMAP server, we cannot allow them a 
mail filtering program such as procmail (if anyone has ideas on this, let 
me know).  So, I'm writing a simple program that will filter a user's 
current mailbox at login time via IMAP.

My question is this: it appears to me that, if I use IMAP and only IMAP 
(i.e., I don't write anything in my script that will deal with Unix 
textfile INBOXes), that I can jettison all the code one ordinarily must 
write to deal with mailbox locking, because the IMAP daemon is already 
doing them for me.

Am I correct?  In essence, in an IMAP client/server situation, isn't it 
the IMAP daemon which is the MUA for mail reading, since it is handling 
all the locking issues and mail message formats?

(Oh, by the way, I'm not totally aversive to writing mailbox-locking 
routines, I've just never done it before.  If anyone knows where I can go 
to read everything I ever wanted to know about mailbox locking, please do 
let me know.)
-- 
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] (Robert Bagwill)
Date: 2 May 1995 17:50:23 GMT

Trey Harris ([email-masked]) wrote:
: Since my users operate over a sealed IMAP server, we cannot allow them a 
: mail filtering program such as procmail (if anyone has ideas on this, let 
: me know).  So, I'm writing a simple program that will filter a user's 
: current mailbox at login time via IMAP.

You don't have to install procmail as a delivery-time filter.  Using the
-m flag, users can invoke it themselves, or it can be invoked on their
behalf by a script.  Of course, I don't know what your configuration is,
so I don't know if that's feasible for you.

--
Bob Bagwill <[email-masked]>

---

From: [email-masked] (Rick Troxel)
Date: Wed, 3 May 1995 01:17:02 GMT

In article <[email-masked]> [email-masked] (Trey
Harris) writes:

Procmail includes a standalone utility, lockfile, that is emminently
suitable for calling from a script.  You'd need to build it on the same
host where your IMAP client would reside.

Regards,
--
Rick Troxel     [email-masked]     [email-masked]     301/496-4823
///////////////////////////////////////////////////////////////////////////
     All effort and exertion put forth by man from the fullness of his
     heart is worship, if it  is prompted  by the  highest motives and
     the will to do service to humanity.                 --Abdu'l-Baha

---

From: [email-masked] (Trey Harris)
Date: 6 May 1995 03:59:02 GMT

In article <[email-masked]>,
>so I don't know if that's feasible for you.

The problem is not that procmail does its filtering at delivery-time (and 
.forward files are not available) but rather that home directories are 
not available to the mail server and /var/spool/mail is not available to 
the login machines.  Maybe there's some way to do it, but the ways I can 
think of are pretty hairy and would require sysadmin intervention 
whenever the user wants to change one of his or her filtering rules--not 
feasible with 20,000 users!

---

From: [email-masked] (Trey Harris)
Date: 6 May 1995 15:48:39 GMT

In article <[email-masked]>,
Mumit Khan <[email-masked]> wrote:
>In article <[email-masked]>,

>Trey Harris <[email-masked]> wrote:

>Do you have a central mail server with a /var/spool/mail where ALL the
>mail gets delivered? If this spool directory is not available on the
>clients, then how do the user read their email? Obviously not on the mail
>server, since you say that the home directories are not available there.
>(Am I reading your message completely wrong here?)

Um...we were talking about IMAP, right?  How else?  That's the real 
reason to use IMAP, to offload all the mail access services from your 
login machine to your IMAP server.  And frankly, I don't especially want 
lots of procmail stuff, etc., running on that server, since it's running 
fairly smoothly and sometimes jerkily with just sendmail and imapd running.

>Our setup is a bit weird -- we have machines in 2 different locations with
>a rather reasonably large latency link in between (and can be flaky at 
>times), so mounting /var/spool/mail is out. We've chosen, rather, to route
>all incoming messages via a set of MX'd central mail servers (via sendmail
>alias map) to the machine that serves user's home directory and then have 
>procmail deliver it locally to their home directories.

I'm glad it works for you, but it sounds like a nightmare when I apply it 
to my site, which has 20,000 users currently (but a growth rate of 200% 
per year!).  Considering that all of my machines are in one machine room, 
connected by a high-speed fiber net, I don't see the latency concerns as 
a problem.

I saw source somewhere for a rewrite of /bin/mail that, when used for
delivery, checked to see if it was attempting to deliver over an NFS link,
and if so, would abort the save and deliver the mail message to the NFS
server via SMTP.  Nifty.  (I've also heard that that's what SPARCs do by
default, but I'm unable to verify that.)
-- 
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] (Mumit Khan)
Date: 6 May 1995 04:37:51 GMT

Our setup is a bit weird -- we have machines in 2 different locations with
a rather reasonably large latency link in between (and can be flaky at 
times), so mounting /var/spool/mail is out. We've chosen, rather, to route
all incoming messages via a set of MX'd central mail servers (via sendmail
alias map) to the machine that serves user's home directory and then have 
procmail deliver it locally to their home directories. No NFS locking 
nightmares and the users have no problem running procmail or other filtering
agents (such as slocal) via their .forward entries after the local delivery 
is done. It turned out to be extremely stable and scalable as we add/remove
users and add/remove file servers where users are served from. We simply
don't have to deal with /var/spool/mail (or /var/mail) anymore and it's a
good thing! There were about a list of dozen or so gotchas we had to deal
with, but it was easy and done over a weekend. For sites that don't allow
.forward (for security reasons or what not), user's can simply write
procmail wrappers that wait for mail arrival to their MAILBOX and deal
with it accordingly (either wake up every so often or work like biff).

mumit -- [email-masked]
http://www.xraylith.wisc.edu/~khan/

---

From: Mark Crispin <[email-masked]>
Date: Mon, 1 May 1995 22:55:13 -0700

You're on the right track.  If you use the c-client API, you could
support both local and IMAP mailboxes, since c-client has all that stuff
in it.

You probably do *not* want to write your own locking code if you can avoid
it.  If you want to hear why, take me to the nearest pub, order a pitcher
of beer, and hear the tale of sorrow and woe... ;-)  Anyway, yes, if you
only use IMAP then you won't have any locking to worry about.

-- Mark --

DoD #0105, R90/6 pilot, FAX: (206) 685-4045  ICBM: N 47 39'35" W 122 18'39"
Science does not emerge from voting, party politics, or public debate.