"The Linux Gazette...making Linux just a little more fun!"

Installing a POP Daemon on Red Hat Linux

From Hongwei Li on Sat, 22 Jan 2000

Hi,

I recently installed RedHat 6.0 and 6.1 on two machines, respectively. Everything looks working except that users can not access their e-mail accounts on these two servers from PC Windows using Netscape Mail or MS Outlook Express although they can access the e-mails using telnet, pine. Apparently, POP3 daemon is not working on these two RH Linux boxes.

Somebody said I can retrieve POP3 daemon from IMAP package. But, I don't know where it is and how to do it. Could you help me? How to check the system if POP3 daemon is installed and working? Where can I get IMAP package and retrieve POP3 daemon, then installed it and let it run? or should I get something else?

I would greatly appreciate your help!

Hongwei Li

Your "somebody" is a smart cookie. You sould listen to him or her. However, you might ask him (or her) for a wee bit more detail.

Red Hat inexplicably puts their POP and IMAP daemons in the same file. You can install them using something like the following procedure:

1) Mount your RH Linux CD (disc #1?) using a command like:

mount /mnt/cdrom

2) Go to RPM directory using something like:

cd /mnt/cdrom/Redhat/RPMS

3) Install the imap....rpm package using a command like:

rpm -Uvh imap*

... or:

rpm -i imap*

That's basically all there is to it. You can test for POP installlation/accessibility using a command like:

telnet $TARGET 110

... where $TARGET is replaced with the hostname or IP address of the system on which you hope to find a POP server.

If you get a "connection refused" or a "connection closed by remote host" then you don't have POP installed properly on the $TARGET system (or you have a firewall, packet filter, or /etc/hosts.deny rule between your client and the server).

Otherwise you should get something a little like this:

Trying 123.45.67.8...
Connected to popserver.wherever.not.
Escape character is '^]'.
+OK <13260.948530011@popserver.wherever.not>
USER nobody
+OK
PASS somedumbpassword
+OK Mailbox open, 4294967295 messages
QUIT

The USER, PASS and QUIT commands were typed by me. There are additional POP 3 protocol commands you could use to play with the server manually, but this is enough to verify that the server is running, that the user name and password are valid and that the POP server isn't having trouble opening the user's mail spool.

NOTE: The PASS command is simply transmitting and displaying your password. Don't do this over an insecure network or with a bad person looking over your shoulder!

(Also note: The number of messages that the POP daemon reports as being in your inbox had better be alot less then what I show in this example: 2^32 - 1).

As for you question about whether you should get something else (something other than the POP daemon that Red Hat packages in their IMAP RPM file): That's entirely up to you.

I did dig up a page where Cameron Laird started collecting notes for a comparison of POP daemons (http://starbase.neosoft.com/~claird/comp.mail.misc/POP_comparison.html)

It doesn't offer much commentary nor comparison, yet. However, it does offer links to over a dozen POP servers. Surprisingly I couldn't find any other online articles that offer a comparison or summary of POP daemons and server.

One of the most popular POP daemons is QPopper (http://www.eudora.com/freeware/qpop.html). This is a (relatively) free package from the publishers of the Eudora mail client software for Macs and MS Windows. One of the principle advantages of this package is its support for changing passwords through it's own client/server protocol. To enable this you have to install the poppasswd daemon in addition to the qpopper daemon.

If you replace your MTA (mail transport agent) with qmail then you'll want to switch to the qmail-pop3d daemon (which comes with qmail). You can find out more than you wanted to know about that and many addons, and optional packages and patches related to it by searching the Qmail home page (http://www.qmail.org) on the term "POP."

It's a pity there isn't more info to guide users in selecting a POP daemon. Then again, basic POP is a pretty protocol with only a very focussed purpose. Any of them should do the basic job at hand.

If you're allowing POP from outside of your network (beyond your organization's firewall or packet filters) then you should require APOP authentication or you should ensure that your outside clients are connecting through a secure channel (like FreeS/WAN http://www.xs4all.nl/~freeswan or an ssh tunnel).

APOP is an extension to the POP protocol that uses a challenge-response exchange to perform the authentication (there's also a KPOP variation for sites using Kerberos). What is remarkable is that I don't see options in any of the software that I've looked at to DISABLE plain text passwords (so that you can enforce a policy that your external users MUST use APOP).

It doesn't sound like this will be a problem for you, but if it is (and for the benefit of my other readers) here's a couple of links to information about POP over ssh, and how to configure a system to allow POP and/or IMAP over SSL (secure socket layer).

Secure POP via SSH mini-HOWTO

http://www.linuxdoc.org/HOWTO/mini/Secure-POP%2BSSH.html

linuxsec: [linux-security] Re: POP secure access??

http://www-uxsup.csx.cam.ac.uk/lists/linuxsec/0104.html

Hope all that helps.

IMAP/POP daemon on RH 6.0 and 6.1

From Randall Gellens on Sun, 30 Jan 2000

One of the most popular POP daemons is QPopper (http://www.eudora.com/freeware/qpop.html). This is a (relatively) free package from the publishers of the Eudora mail client software for Macs and MS Windows.

Why do you say "relatively"?

I was under the misconception that Qualcomm was imposing some restrictions on the distribution of qpopper derivatives. However, I copied you so that you could clear that up for me. (I see that it's not listed as "non-free" by my Debian package lister and now I see that it appears to be a BSDish license.

So, I was wrong to qualify it this way. Qpopper is a free package.

If you replace your MTA (mail transport agent) with qmail then you'll want to switch to the qmail-pop3d daemon (which comes with qmail). You can find out more than you wanted to know about that and many addons, and optional packages and patches related to it by searching the Qmail home page (http://www.qmail.org) on the term "POP."

Many people use Qpopper and Qmail together. There is a ./configure option for Qpopper to use Qmail's home dir mail spool.

Glad to hear it. I obviously haven't been using qpopper recently. I should probably switch.

APOP is an extension to the POP protocol that uses a challenge-response exchange to perform the authentication (there's also a KPOP variation for sites using Kerberos). What is remarkable is that I don't see options in any of the software that I've looked at to DISABLE plain text passwords (so that you can enforce a policy that your external users MUST use APOP).

By default, Qpopper does not permit users to log in with plain text passwords if they are enabled for APOP (or SCRAM).

Maybe the FAQ or README should clarify that. Maybe I missed it. That's one of the reasons that I try to copy the "right" people when I'm doing my "Answer Guy" responses. I learn from my mistakes that way.

Is SCRAM some variant of the CRAM-MD5? (challenge/response authentication mechanism: RFC 2095 and 2195?)

Does that get around the need to store the POP user's cleartext password on the server? I read through these RFCs and didn't quite get the part about storing "contexts" rather than copies of the cleartext passwords. (I didn't spend long on it, but I think I'm missing some detail here --- I should probably read some source code to an implementation to see what I missed).

Randall Gellens
Opinions are personal; facts are suspect; I speak for myself only
--- randomly selected quote ---
A child of five would understand this. Send somebody to fetch a child of five. --Groucho Marx, _Duck Soup_

Copyright © 2000, James T. Dennis
Published in The Linux Gazette Issue 50 February 2000

HTML transformation by Heather Stern of Starshine Technical Services, http://www.starshine.org/

					1	2	3	5
				5	6	7	8	9
10	11		13	14	15	16	17
18	19	20	21	22	23	24
26	27	28	29	30	31	32	33
34		36	37	38	39	42	41
42	43	44	45	46	47	48