Hi
Paul J Stevens wrote:
Aaron Stone wrote:
Serious, yes, but show stopper, no... that mail is delivered and is
not lost.
I would still call it a show stopper in terms of final release, because
it would cause both users and system administrators who rely on this
feature major headaches when suddenly inboxes are swamped by messages
normally filtered out into other folders.
I've been thinking about what kind of QA we can offer in the future. Is
something like unit-testing feasible ? I come from a python background,
and we never build stuff anymore without a test-framework. Also, an
expect(1) based test setup for the daemons would also be a boon, I think.
I've been thinking about the same thing. Earlier on, I've made some
simple python scripts using imaplib and poplib to check if everything
functions well. The problem was that I did not really find any problems
that I or somebody else later discovered by accident. This could also be
due to my scripts being too simplistic of course :)
It might be a good idea if we come up with a nice test suite.
I'm planning to test the ldap-auth module over the next week. Has anyone
done so already? If so, what is the status of:
- ldap account creation and maintenance using dbmail-adduser.
- authentication and delivery.
Especially the latter should be well testing imo before release. Account
maintenance can be done through other means, but without authentication
and delivery I won't even bother building packages with ldap enabled.
I haven't looked at the LDAP in a while. As far as I can see, LDAP is
not nearly finished and/or stable. We have to take a good look at how
the data in LDAP should interact with the data in the SQL database. For
now, I can see a problem regarding the calculation of the mailsize of a
user. This is now done using fields in the users table, with some nice
joins with the mailboxes, messages and physmessage tables. When using
LDAP, this cannot be done. There are bound to be more problems. In fact,
every query outside in db.c that uses the users table is suspect.
I think we have to move to a system were we have a users table with some
things like curmail_size, but have all non-so-often-mutated data in a
different table, or in LDAP (or possibly even flat files).
This way, we have no problems with foreign keys in SQL. Also, it takes
care of not having to write the curmail_size to LDAP on every mutation
of the mailboxes (insert, append, delete etc).
Also, thunderbird now performs adequately with Ilja's acl fix. But
connections are still quite flakey. I still see massive numbers of EPIPE
errors in the syslog. A typical sequence reads:
Mar 20 15:42:50 tsuki dbmail/imap4d[32195]: PerformChildTask(): incoming
connection from [172.16.3.2]
Mar 20 15:42:50 tsuki dbmail/imap4d[32195]: COMMAND: [1 authenticate login]
Mar 20 15:42:51 tsuki dbmail/imap4d[32195]: IMAPD [PID 32195]: user (id
5, name someuser) login accepted @ 2004-03-20 15:42:51^M
Mar 20 15:42:51 tsuki dbmail/imap4d[32195]: COMMAND: [2 STATUS
"somefolder" (UIDNEXT MESSAGES UNSEEN RECENT)]
Mar 20 15:42:51 tsuki dbmail/imap4d[32195]: COMMAND: [2]
Mar 20 15:42:51 tsuki dbmail/imap4d[32195]: IMAPClientHandler(): error
[Broken pipe] on write-stream
And this is repeated over and over for each mailbox checked. And it
means thunderbird is unable to check all folders for unread email with
option: user_pref("mail.check_all_imap_folders_for_new", true);
And finally, I've done some testing on shared folders. When I set the
ACL lookup and read flags, but not the seen flag (which is a use-case I
use as a selling point for dbmail; office-manager sets read flags on
incoming mail only after an issue has been assigned to a co-worker,
while the co-workers can only read and download mail), thunderbird
becomes very confused.
How does it become confused?
You mean to say 'dbmail-smtp -m somefolder -u joe -u jane' would then be
valid ?
This is completely valid right now. It sends mail for joe and jane to
their folder named somefolder (which is created if it does not exist yet)
Ilja
