Note to those not following the thread: if nothing else, an interesting rationale for separating the concept of filtering and sorting as being part of the MTA and MDA, respectively, is way down in an inlined reply. I think it's a pretty good read ;-)
Aaron Bill Hacker <[EMAIL PROTECTED]> said: > Aaron Stone wrote: > > > I'm not sure what you mean by "DBMail relies on external daemons for IMAP" > > because dbmail-imapd is most certainly part of DBMail and not external, > > ala Courier or something like that. We have full control over how we want > > our IMAP server to behave, and in this case, what the path delimiters are. > > Now if I actually remember what the delimiter is... > > Perhaps I have been under a mistaken impression, but, IIRC the docs had > instructions on how to configure DBMail with other (required) MTA's. If > that appleis only to the SMTPd (and POP3d) and the IMAPd is *not* > external, then there is a great deal more flexibility open to the devel > team... > DBMail manages everything about the mail store. That means is has a way to get mail in through communications with the MTA and ways to get mail out, through IMAP and POP3 protocols with the MUA. Literally the only piece of the puzzle DBMail doesn't touch is SMTP. There are dozens of good SMTP servers out there, each one bigger than all of DBMail! > > > > I believe that the best way to handle spam is by using an MTA based spam > > checker which adds identifying headers, prefixes the subject line, or > > otherwise marks the incoming email without disrupting the MTA path towards > > DBMail delivery. > > > Certainly the method that keeps junk out of the DB, but, IMNSHO, also > the method which potentially imposes the greatest delay in handling > inbound messages. And, per other MTA authors, effective spam filtering > is a 'non-trivial' load. > > IOW - filtering-to-mark is nearly as cycle-consuming as > filtering-to-drop-on-the-floor or redirect, though perhpas less abusive > of an open connection than filtering-to-'reject'. There isn't anything that DBMail can do to speed up spam filtering. It is what it is; get a better spam filter, or write your own! But how the delivery chain is configured *is* a big deal, and is something that DBMail should be quite concerned with. Part of my work on Sieve support has been rewriting the message delivery process to be common among the various daemons and tools and to include code to interface with libSieve and store Sieve scripts in the database. I could certainly see a step along the path that involves running a spam checker, and I could see a Bayesian type thing happening with per-user spam keywords stored in the database. There are several libraries out there that implement a Bayesian filter to be used in a manner such as this. So should we do that? It's questionable. There is exactly one standardized mail sorting language, Sieve, and there is a standardized network protocol for managing Sieve scripts on a closed server (albeit an expired draft...) This makes it easy to choose how to implement the general request for a sorting mechanism. With spam, there are dozens of good quality spam checkers. Further, some of them are at the MTA level and some at the MDA level. It would be a shame if we said, "This is the one and only spam checker DBMail works with." > > > At delivery time, use a Sieve script to put all of the spam into a folder, > > or discard it, or keep it in INBOX, or bounce it back, or call you pager, > > etc. > > > ACK. > > > It would also not be unreasonable to have a default Sieve script that does > > this, although I'd have to add default scripts to my TODO list and it > > would certainly be 3-6 months before I have the code sketched out. > > Open source means it should be 'borrowable', with due credit & license > etc. Not a new need. > I'm the one writing the Sieve patches. At this point in the process, it's a one man job. Too many cooks in the kitchen... Once I have the basic Sieve stuff together and it's been included into the mainline DBMail, anyone else could, and should, look into writing a the various auxiliary pieces. Just noting that if nobody else does, I will, but at least 3-6 months from now. > > > > BTW - As some may have seen my numerous freshmeat releases this month, I've > > been busily working on libSieve and should have 2.2.0 stable and with a > > fully > > frozen API in the sometime-between-now-and-1/1/2004 timeframe. > > > > Aaron > > > > > > Bill Hacker <[EMAIL PROTECTED]> said: [snip] > > > >>Feargal Reilly wrote: [snip] > >> > >>>Finally, as I mentioned, I have no experience with IMAP, so should a > >>>spam mailbox be called 'Spam', '/Spam', or something else? > >>> > >> > >>So long as DBMail relies on external daemonss for IMAP, it is likely to > >>be 'INBOX.<something>', but I would suggest a short name "other than > >>SPAM", on the grounds that: > >> > >>- IF we were *certain* it was spam, we probably wouldn't deliver it at all. > >> > >>- "Probable spam" seems appropriate if the luser wishes to reiew it in > >>case his filters are over zealous, but may be too long a name for > >>convenience... > >> > >>- How about "Suspect" (INBOX.Suspect) > >> > >>Bill Hacker > > Regards, > > Bill Hacker > > > _______________________________________________ > Dbmail-dev mailing list > Dbmail-dev@dbmail.org > http://twister.fastxs.net/mailman/listinfo/dbmail-dev > --
