Thanks for getting into the Wiki thing, it's the best way to keep track of what happens through a mailing list discussion.
On Wed, Apr 20, 2005, listmember <[EMAIL PROTECTED]> said: [snip] > A lot of the stuff that has been clumsy to do in IMAP can be easily > handled by a good enough RDBMS --I am biased towards PostgreSQL and > Firebird/Vulcan. [yank] > I just hope that you guys have glance at those pages and incorporate > some of the ideas into the infrastructure --clients will follow. I strongly disagree with tying DBMail too tightly to any particular database. I know that MySQL < Perfect (TM), but it's popularity builds our popularity. Add to that the fact that MySQL is growing features at about the same rate as we're able to build them into DBMail, and the relationship is golden. I'm not making a MySQL specific defense though; the same goes for SQLite and all sorts of other backends we might eventually use. The best database integration will really come only when half of DBMail is written in stored procedures. But then we're joined at the hip to a dababase system, and porting to others becomes a massive undertaking, fraught with QA nightmares in terms of testing functionality. There will be come cases where this is the best or only option, and we can make provisions for that through weak symbols during linking, function pointers, etc. All really standard C tricks that will keep us sane and keep the majority of the backend code common and portable. Secondly, "clients will follow" -- oh no they won't. Wanna get left out in the dust? Easy: create your own standards and be the only one to support them. If the protocol isn't standardized and/or reasonably well known and implemented, then it's probably not something we want to touch with a 10 foot pole. [paste] > Auto Replies, Auto Notifications, Mail Client Settings, > Blacklisting and Message Filters are --IMHO-- just some of those > things that DBMail can do much more effectively than other > conventional Mail Servers. Auto Replies & Auto Notification: good ideas to work on. Mail Client Settings: custom protocols bad. See http://asg.web.cmu.edu/acap/ for just how nasty something like this can get even when they are standardized. Blacklisting: not sure if this should be MTA level. Message Filters: I've separated the term "filter" from "sorting" like this: Filters: look for spam, attachments, whitelists, blacklists. MTA level. Sorting: put into folders, local reject, vacation messages. MDA level. Your suggested system basically takes each keyword from Sieve and makes it into a column in the database. We can do this with key/value pairs and eliminate the billion columns problem. But there's no protocol for getting these scripts into the database. So you either need a custom protocol (bad) or a client which directly manipulates the database (limited usefulness). I've been dragging my feet on libSieve because I need some help! At one point there was code for a nifty regex based sorting system. I stubbed it into the sort/sort.c but the rest of the code didn't materialize. Anybody remember this? Aaron
