On Thu, Jun 7, 2007, Tom Allison <[EMAIL PROTECTED]> said: > I'm also a big fan of KISS and strongly believe in the idea that > originated with UNIX programming (opposed to Windows) in that each > program should have a very distinct function and you can enhance > features by making it accessable rather than incorporating everything > into it. > [snip] > The example of a blog and dbmail is a great point. dbmail isn't a > blog server. > > It's still a mail server and someone used the API of IMAP to make it do > something else. This gives you the type of accessability that makes your > software rock -- but it's not dbmail's job to do blogging.
Yep, I do like example quite a bit. I've been thinking of hacking up a proof of concept just for fun. It is indeed a great example of the new things you can do with clearly defined protocol / pipe interfaces. > If you want to make dbmail capable of doing spam filtering... wouldn't > it make more sense to simply pipe the spam filtering in front of the > dbmail interface like procmail does today? I'm stuck on this one. [snip] I'm very much on the fence with spam filtering. I hate all of the setups I've put together on my own system. They all have absurd gotchas and hoops to jump through. I've been thinking about how to expose spam filtering through Sieve, and then using a sitewide sieve to call it. The draft standard Sieve commands are here: http://tools.ietf.org/wg/sieve/draft-ietf-sieve-spamtestbis/ then it's just a matter of mapping the spamtest tests onto some actual spam checking system, be it header checks for X-Spam-Whatever, or library calls to a spam testing suite. > But I can say "I don't get it" and can someone provide me with a case > where it's a "good thing" or better than what's available today? I would indeed like more use cases from folks who are interested in particular features. A great use case makes something worth working on, even if it's something obscure. > Personally, I would be more impressed if someone would fix SIEVE so it > could make external calls in the same fashion that procmail/maildrop do. > Sieve is nice because it allows you to "stay off the disks" by keeping > all the rules and processing both in the database and per-user > configurable. This makes virtual mail configurations much easier. On the contrary, _not_ being able to make external calls is a major reason to use Sieve. I could certainly see making a vendor extension to libSieve that allowed external calls for certain privileged scripts, but we'd have to weigh that against some serious security considerations. [snip] > I would love it if you could make rules that are in groups of global, > by domain, by user. But I'm not sure I can do this. Not really tested. > Can you? Not yet. The idea only came up a few months ago, and I think it's a fantastic idea, but haven't written the code for it yet. It turns out several Sieve implementations are doing this, but it was sort of a vendor extension nobody who'd done it had mentioned. I brought it up in a Sieve WG meeting and everyone in the room said either, "Oh yeah, mine does that," or, "Wow, that's a great idea!" I'm in that latter group ;-) > It was also be nice to make external calls like you can with > procmail (pipe in from dbmail, do something, pipe out to dbmail again). Piping things in and out for specific aliases (which can include domain aliases, btw) is already possible, although you might have to jump through some weird aliasing hoops. Aaron _______________________________________________ DBmail mailing list [email protected] https://mailman.fastxs.nl/mailman/listinfo/dbmail
