From rfunk Tue Sep 29 12:12:39 1998 Subject: Re: [COLUG] imapd To: Date: Tue, 29 Sep 1998 12:12:39 -0400 (EDT) hunter wrote: >The imapd server is a method, probably the next major method method, for >access to email on a central, _capable_ server. The mail remains on the >server, and the headers are downloaded, and manipulated. It is a mature, >stable, secure product in the recent incarnation. There are at least two >OpenSource implementations. > >Because it was installed 'turned on' in RH 4.2, the crackers found a >buffer overflow in the older version RH shipped, and use it to take over >remote hosts, when the unpatched version is left on ... I want to emphasize that this bug is in an OLD version of the University of Washington IMAP daemon, and is fixed in the current version (including the current Red Hat distribution). This one bug has done more of a disservice to both IMAP and Linux than any other I know. Because of it, many people think that Linux is an insecure OS or that IMAP is an insecure protocol to be running, neither of which is true. It was a problem in one implementation of IMAP, and that implementation was fixed long ago (last year). The lesson is to be aware of what network services you are running, don't run any that you aren't using, and stay aware of the security issues of those you are using. Anyway, to add to what Phil said about IMAP... IMAP is like POP grown up. It offers everything that POP does, plus makes it easier to deal with your mail remotely, without downloading everything first, so it can be an excellent replacement for having the mail spool available on a mounted filesystem. I primarily use IMAP (with fetchmail) for its ability to access multiple folders per user (an ability the defunct POP2 had also), but it's also nice to have the ability to manipulate my mailbox(es) remotely, without downloading everything. >The driving force, Mark Crispin, at UWashington, is a bit terse -- a 'read >the source, Luke' and 'RTFrfc' in attitude. Netscape, MS, and IBM imapd >server development types are active list participants. > >PINE, NS 4.05 and later, and MSIE 3.? support it as mail reading >and management clients; We have been working with NS TS in filing off >rough edges in 4.5, in beta. It should be mentioned that Crispin is the primary author of the IMAP RFC(s), the UW-IMAP daemon, and Pine. So Pine and UW-IMAP can be considered the canonical implementations. Mutt (the modern mailer for elm fans) also has support for IMAP now. The program is still a bit unstable though.
From Thu Mar 18 21:11:31 1999 From: (Rob Funk) Subject: Re: [COLUG] Mail Server In-Reply-To: <> from "Lambermont, David" at "Mar 17, 99 02:34:39 pm" To: Date: Wed, 17 Mar 1999 15:28:57 -0500 (EST) Lambermont, David wrote: >My question is, how do I get the mail from the mail server to accounts on >the other two machines on my LAN? I rarely login to the firewall any >longer, except to check logs and view my uptime, so I've been using my old >pop-mail account on RoadRunner for the time being. On the server side, you could make it available via NFS, POP, or IMAP. My recommendation is IMAP, since it's functionally a superset of POP and should give all the message handling ability you need, and NFS has a bunch of drawbacks (especially locking) since it wasn't really designed for mail. Assuming you use POP or IMAP, the question then becomes how to get to the mail from the clients. You could use a mail program with POP/IMAP capabilities, such as pine, mutt, or netscape. Or you could use fetchmail to get the mail from the server, then use pretty much any mail program to read it. I think using an IMAP-aware program would be easiest if you could be using more than one machine to read your mail. I should mention that in the network I run at work we share mail using both NFS and IMAP (and some people download it with POP). The only reason we're using NFS for mail is that we have stubborn users that don't like change. I did manage to convert one person to IMAP with little hassle though. It helps that he uses pine; most of the rest use elm or Berkeley mail.