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...
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. 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. 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. 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 --
