[horde] poppassd server
rich at horde.org
Sun Mar 18 14:29:14 PST 2001
On Sun, Mar 18, 2001 at 05:03:42PM -0500, Chuck Hagenbuch (chuck at horde.org) wrote:
> Well, what do people think? I came from the same viewpoint, but I
> came around to thinking password changing is big enough of a job to
> be seperated out. I don't think it should be in IMP; there are too
> many specifics. Here are the 4 possibilities I see:
> 1. put in it Gollem. Max sees Gollem as a general account manager,
> handling .forwards, vacation, etc; password changing fits in reasonably well
> with those.
Well, the difference between password changing and .forward and
vacation and so forth is that password changing is a concept that
applies in *some* manner or another to nearly every IMAP setup out
there, while .forward and vacation are very platform-specific.
(Qualcomm came up with poppassd to get around the
Also, I hope we're keeping the model in which IMP doesn't have to run
on the mail server itself, nor access its filesystems; that means that
unlike .forward and vacation and filtering, password changing has to
work remotely. (We want to avoid *losing* functionality that's now
> 2. put password changing right into Horde.
More on this later.
> 3. put it into its own app.
Seems like overkill to me.
> 4. take all of the account-management stuff (vacations, forwards,
> passwords) out of Gollem and make all of them into their own app,
> leaving Gollem just to do ftp.
> Listing them out that way, I'd go for #1 or #4. Let the discussion rage.
Hrm. So if we view Gollem's tasks as (a) password changing, (b)
forward/vacation/filtering, (c) FTP, then we end up with a whole bunch
(a) is pretty much universal, and is useful for both mail,
fileserver, and shell accounts (except for SecureID, s/key, and
(b) has to be platform- and MTA-specific (since it needs to know
filenames, whether to use .qmail-forward or .forward, whether
to use procmail or eximfilters, and so on -- which seems to
lend itself to modularity, and is distinct from ftp/shell bits;
(c) is distinct from mail.
Let's say we go with (4); then if you want Gollem but not IMP and you
want to let people change your passwords, you've also got a bunch of
mail-related things lying around; that just replaces the current
problem (letting mail-only users change passwords involves something
designed for file stuff) with the opposite (letting file-stuff-only
users change passwords involves mail-ish things). So, (4) doesn't get
us any further ahead except that more people will probably offer
mail-without-file than file-without-mail.
What about (2), then? If password-changing routines -- both remote
poppassd and local talk-to-/bin/passwd-or-PAM versions -- are part of
the general Horde stuff, then every Horde application that needs to
change a password has that facility.
In other words, it strikes me that password-changing is something that
will generate a dependency -- no matter where we put it, other
programs are going to depend on whatever it's put in. But the other
applications themselves aren't necessarily that dependent on each
other. So, if we want to minimize the number of programs people have
to install for features they don't want (in particular, consider the
cases of a webmail provider that doesn't want filter/forward/ftp, an
x-Drive/iDrive type thing that doesn't want mail, and a netnews
provider that doesn't want either) then password-changing is going to
need to be in its own place. Since pretty near every component's going
to need *some* sort of password-changing, and since it's probably too
trivial and too pervasive to be an optional standalone component, then
it's pretty much at home as part of Horde proper.
------------------------------ Rich Lafferty ---------------------------
Sysadmin/Programmer, Instructional and Information Technology Services
Concordia University, Montreal, QC (514) 848-7625
------------------------- rich at alcor.concordia.ca ----------------------
More information about the horde