Aaron Stone wrote:
Two weeks ago Paul suggested a 2.1.0 release. I've been thinking about it,
and about these suggested changes for 2.0:
* Bug 125: Inefficiencies in ACL listing.
* Bug 133: Inefficiencies in Mailbox listing.
* Bug 151: dbmail-util produces too many updates to fix is_header
fields.
That one's easily fixed using the framework I devised for:
* Bug 97: all messages have RECENT flag in IMAP.
which is already fixed in cvs-head.
* Bug 129: Config file parser should be more robust (backport from
2.1?)
That last one, which started out with the suggestion to backport from 2.1,
that's the way to do it. The ACL and mailbox inefficiencies are indeed
best fixed in 2.1; they'll be rather invasive fixes. Same with \\Recent
flag.
Actually the recent flag fix was not really invasive. I know how to do it. It's just that to do it for 2.0 I
have to reinvent a couple of calls that were *so* easy in glib.
Once stable, I am all for backporting them to give a big boost to 2.0 and
allowing it to remain the flagship release until we're ready for 2.2.
Agreed then.
So, in short, Paul you've got me for 2.1 ASAP :-)
Great. Because I could use some help. I'm speeding along the authldap completion. But I've also redone the
dbmail-users -l output. Output from dbmail-users should, imo be both human readable *and* machine parseable.
That's why I've changed the output to emulate the getent (/etc/passwd) format. Doing so I've also fixed a long
standing annoyance: if you do a dbmail-users -l [EMAIL PROTECTED] it will list *all* entries that match,
not just the first.
I'll do some additional tests today and checkin so you can see what I've done.
The main hurdle I have to take in authldap before completion is external
forwards.
Supporting external forwards in dbmail-users is pretty straightforward but only if we can assign such forwards
to a particular user. This is a different sematic compared to authsql of course where external forwards are
totally separate from the users.
I see two ways to solve this: assign external forwards to specific users. Very easy to do: a simple
ldap_modify call will suffice. But this means that external forward are a change action performed upon users.
Or we can use a special or limited objectclass path to map external forwards (only attributes mail and
mailForwardingAddress required). But this could quickly become too painful and complex to support cleanly.
So I think I will follow the path of least resistance and assign forwards to users. See where that leads us.
Of course dbmail delivery will perfectly support forwards that are not assigned to users. In authsql that is
the natural way of things. For authldap this would however require the ldapmanager to use other means of
creating those forwards than dbmail-users.
later,
--
________________________________________________________________
Paul Stevens mailto:[EMAIL PROTECTED]
NET FACILITIES GROUP PGP: finger [EMAIL PROTECTED]
The Netherlands________________________________http://www.nfg.nl
