Very Computer

Tossing this into CAL.questions didn't get an answer - so maybe
this is more appropriate here.

Ok, I know little or nothing of *n*x mail handling daemons,
and I don't want to learn the ins and outs of ALL of them....

I am looking at doing a set up on a few home/training networks
to allow mail to be shared between multiple clients.  It seems
that setting up an IMAP server on the gateway RedHat linux
boxes is the most client independent method of doing this.

I want to end up with stored mail functionality roughly
equivalent to the local Netscrape folders capability -(or M$
exchange server with less hassle)- multiple 'folders' on the server
for each user, and all available from any client that
can handle imap.  (Or am I misunderstanding here - are the
multiple 'folders' a function of Netscrape, not the server?)

Ideally, the clients do NOT have real accounts on the mail server
box (pop/imap only clients?) - and the mail-fetch script (only
runs while ppp is up) would sort the mail according to some
rules and drop it into the appropriate user's inboxes.

Security is not a significant consideration - the server would
only be accessible to internal clients, with no access allowed
through the firewall. Incoming mail would be fetched from the
ISP's POP3 server. Outgoing mail would be a direct (masqed)
connection to the ISP's SMTP server.

Of course, there's more than one way to do this. My thoughts
are to just use the RedHat IMAP server with fetchmail. Is
this sufficient to do the job? (And do I need to use
sendmail and/or procmail in there?)

Before I go off to RTFM (assuming I can find a suitable FM)
on these two packages, perhaps someone would have some
ideas or opinions on alternate servers or methods?

----------------------------------------------------------
Liquor       So I want to get rid of Outlook....
               _before_ it gets rid of me.

To mail me, remove the dot spamstopper

Hello!

No, the folder stuff is IMAP.  Telnet to your favorite imap
server (port 143) and you can try this

$ telnet imapserver.com 143
 Trying 123.123.123.123...
 Connected to imapserver.com.
 Escape character is '^]'.
 * OK imapserver.com IMAP4rev1 v12.666 server ready
tag1 login username p4ssw0rd
 tag1 OK LOGIN completed
tag2 select INBOX
 * 290 EXISTS
 * 0 RECENT
 * OK [UIDVALIDITY 949639672] UID validity status
 * FLAGS (\Answered \Flagged \Deleted \Draft \Seen)
 * OK [PERMANENTFLAGS ()] Permanent flags
 * OK [UNSEEN 250] first unseen message in /var/spool/mail/username
 tag2 OK [READ-ONLY] SELECT completed
tag3 logout
 * BYE imapserver.com IMAP4rev1 server terminating connection
 tag3 OK LOGOUT completed

The thing to note is that you select the box (folder) before fetching
the mail.

Quote:> Ideally, the clients do NOT have real accounts on the mail server
> box (pop/imap only clients?)

There's no need for users to have accounts, in fact I usually have
a "no login" account just for fetching mail - that way having the
password stolen or sniffed means that only my email has been
compromised, not the entire system.

Quote:> and the mail-fetch script (only
> runs while ppp is up) would sort the mail according to some

I have used both the default imapd installed with Linux (UM, I think)
and cyrus imap.  I find that cyrus is worth the extra hassle of
installing it because it has

        - many authentication schemes (through sasl)

        - fine grained access control that allows you to
        easily create shared boxes (granting subscribe,
        read, post or delete priveleges on a per user
        basis) that can act as anything from a newsgroup
        to a restricted, read-only message board.

        - quotas on a per box or folder basis

        - messages in a box are not melted into a single
        huge "Berkeley" format file, making fetching a given
        email faster and helping incremental tape backups
        stay smaller (only the recent msgs are archived, not
        the large mailbox file).

        - pop3 daemon that uses the same message file formats

        - the ability to deliver to any subfolder

That last point seems directly relevant to your case. A small perl
script could allow you fetch the mail from one or more locations,
parse the messages and store them in the correct box or even
subfolder.

I have used this to create a shared "devel" email address: mail
sent with "RFC" or "BUG" or ... is automatically stored in the correct
subfolder (using the cyrus delivery agent with the -m switch).

HTH
Pat D.

I'm not sure, but I'll answer it anyway.

Quote:> Ok, I know little or nothing of *n*x mail handling daemons,
> and I don't want to learn the ins and outs of ALL of them....

> I am looking at doing a set up on a few home/training networks
> to allow mail to be shared between multiple clients.  It seems
> that setting up an IMAP server on the gateway RedHat linux
> boxes is the most client independent method of doing this.

I do exactly this at home, and it works very well. (Using Redhat 6.1 and
the UW IMAP server.)

Quote:> I want to end up with stored mail functionality roughly
> equivalent to the local Netscrape folders capability -(or M$
> exchange server with less hassle)- multiple 'folders' on the server
> for each user, and all available from any client that
> can handle imap.  (Or am I misunderstanding here - are the
> multiple 'folders' a function of Netscrape, not the server?)

This is a function of the IMAP protocol and server, though there are a
few complications you should be aware of: Using the default setup,
(unix-style mailboxes) you can't have a folder that contains both
messages and other folders. You can do this using the maildir format,
but if you're going to do that, you should probably look into the Cyrus
IMAP server, especially if you're concerned about performance.

Quote:> Ideally, the clients do NOT have real accounts on the mail server
> box (pop/imap only clients?) - and the mail-fetch script (only
> runs while ppp is up) would sort the mail according to some
> rules and drop it into the appropriate user's inboxes.

Well, they need passwords, mail spools, and a place to store their mail
folders (home directories). I'm not sure what you're definition of an
account is, but it seems pretty much impossible to have all those things
without a true account. What you can (and should) do is set the users'
shells to /bin/false or something equivalent so they can't log in.

Quote:> Security is not a significant consideration - the server would
> only be accessible to internal clients, with no access allowed
> through the firewall. Incoming mail would be fetched from the
> ISP's POP3 server. Outgoing mail would be a direct (masqed)
> connection to the ISP's SMTP server.

Good, there have been exploits against holes in imapd in the past.
They've been fixed, but it's probably not the kind of thing you want to
run on an ultra-secure server.

Quote:> Of course, there's more than one way to do this. My thoughts
> are to just use the RedHat IMAP server with fetchmail. Is
> this sufficient to do the job? (And do I need to use
> sendmail and/or procmail in there?)

fetchmail delivers mail to an MTA (like sendmail) by default. It is
possible to configure it to deliver directly to an MDA (like procmail),
which might be the best way to go in your case if you don't want to be
running a full MTA. You'll need some MDA either way you go. IIRC,
procmail is the default for Redhat, so it's probably best to just use
it.

Quote:> Before I go off to RTFM (assuming I can find a suitable FM)
> on these two packages, perhaps someone would have some
> ideas or opinions on alternate servers or methods?

imapd + fetchmail is by far the easiest way to go, and works quite well
too (in my experience). I doubt you'll find a better tool than fetchmail
for downloading mail, though UW imapd leaves a bit to be desired (in
terms of customizability and performance). It's unbelievably simple to
set up, though, so you should start with that and switch if you find it
doesn't meet your needs.

--David Reiss

The moving finger attributed to Pat did write:

<much help>
)
) HTH
) Pat D.

Thank you.

--
Liquor

The moving finger attributed to David Reiss did write:

<Snip of much help>
)
) > Before I go off to RTFM (assuming I can find a suitable FM)
) > on these two packages, perhaps someone would have some
) > ideas or opinions on alternate servers or methods?
)
) imapd + fetchmail is by far the easiest way to go, and works quite well
) too (in my experience). I doubt you'll find a better tool than fetchmail
) for downloading mail, though UW imapd leaves a bit to be desired (in
) terms of customizability and performance). It's unbelievably simple to
) set up, though, so you should start with that and switch if you find it
) doesn't meet your needs.
)
) --David Reiss
)
Thank you sir, I'm off to find the FM.....
--
Liquor