Description of problem:
IMHO, the following is a major limitation / missing feature in dovecot:
Regular users should be provided with a facile way of changing their own
password, without administrator's intervention.
This mechanism should meet the following criteria:
- can be done remotely, in a facile way (via a Web interface ?)
- should be 100% independent of the way users are defined in dovecot (plain text
files, databases, LDAP, etc. )
- users should not be able to modify other dovecot parameters (as they can via
Webmin or other remote administration solutions)
- should be present in the default dovecot repository (probably as a separate
- should integrate nicely with other related packages (sendmail, postfix,
squirrelmail, Fedora Directory Server, openldap, etc.)
I'm marking this as "severity=high" because I consider it of general interest,
for a large mass of users.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
dovecot doesn't provide a way for regular users to change their own password
(without administrator's intervention).
Such a way should exist; it should be accesible remotely in a facile way and
should be independent of the database backend used for usernames and passwords.
It may be possible to extend dovecot-auth to support password changing. The
upstream's plan is to split dovecot-auth and add some general purpose
binaries/libs around it. These may be used from the web frontend, or the
frontend may talk to dovecot-auth itself. The web frontend should not be a part
of the dovecot package. I suppose one can just write a dovecot-auth backend for
an existing password changing webinterface.
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release. Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products. This request is not yet committed for inclusion in an Update
It's not clear what to do, upstream hasn't moved any further in this respect,
and it's too late for 5.2 to start thinking how to do this. We'll have to close
it for now.
Development Management has reviewed and declined this request. You may appeal
this decision by reopening this request.