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