| something that ordinary email users could use to help control the delivery of their email, without having to expose them to advanced or arcane computer tools and environments and complex scripting languages. This means that most users wouldn't even know about the underlying tools, which further meant that the control files need to easily generated by a web-oriented front-end. And yet I also wanted a tool that could be used in powerful ways by more technically advanced users: those who can and do make use of complex tools and environments and scripting languages. |
And if it needs more words than that:
From an administrator's perspective, I wanted to be able to give each user an environment where they could have multiple email folders accessed and managed via IMAP (or, if they only wanted an inbox, via POP). I also wanted to provide them with some kind of programmed control over the delivery of their email. Given that most of these people will be users of email, and not computer professionals, I also didn't want to expose them to overly complicated tools, nor to the underlying system. For that matter, I also did not want to expose the underlying system to those users. And yet, I also wanted to make sure that more advanced users could use the delivery tools in powerful ways, even by creating their own hand-written scripts.
Also from an administrator's perspective, I wanted UNIX shell users to have access to the same kinds of mail delivery capabilities. Why not, for example, just let them have procmail? Well, they certainly can do that. However, if we're building a front-end to generate delivery scripts for non-shell users (the IMAP/POP -only users), we can let the shell users that want that capability use that. Plus, not everybody wants to learn or use procmail: I wanted a equally (if not more) powerful tool for those that might be inclined to turn to it instead.
And also from an administrator's perspective, I wanted a tool that could be used in non-final-delivery places: e.g. as part of a pipeline in mid-delivery, or as a hook into an SMTP server.
From a personal perspective: I'm one of those who would prefer an alternative to procmail. Don't get me wrong, procmail is a fine tool. We don't have a one-size-fits-all world, though, and not everybody has to like the same things. Alternatives are great. I also felt that if I was providing something for other users, it should be something that I not only could use also, but would actually choose to use myself.
And that, in a nutshell, is it.