David Harris writes:
> Let's be fair here: it's not that Mercury doesn't have filtering support - it's that IMAP doesn't have filtering support. Mercury has so much > filtering overall that you could practically sort sand with it. I could easily enough add filtering into the IMAP equation, but there would > be no standard way of manipulating the filters, and no way of having IMAP clients apply the filters on demand; it would all have to be > automatic and rather ad-hoc.
One thing your filtering system won't allow just yet is per-user-specified filters for mail delivered into a specific user's mailbox to be routed to subfolders. That's an essential first step, of course. There can be no GUI; it'll have to be a file dropped in the user's mail directory. A user can update that file to get mail sorted into the proper physical subfolders in their maildrop and observe the benefits in Pegasus Mail, with IMAP or with webmail using IMAP.
I still maintain that doing the filtering on the server automatically is the proper and correct thing to do. Letting clients do it using IMAP is just slow and 'orrible. Letting clients touch the filtering rules in standard filtering language form (Sieve from the IETF, for instance) is a nice idea, except of course that there's no way to do it over the network presently and Sieve still finds greatest usage between cooperating processes on the same box (EG: mail delivery agent / webmail facility). The greatest weakness in a Mercury-backended webmail is that it has IMAP as an exclusive abstraction for Webmail rather than file-based access to filter files and mailboxes, neither of which are really open.
Right now, the Unix world gets the benefit of, for instance, procmail or maildrop (and most recently Sieve's) prevalent usage by most MTAs for mail delivery, both of which support mailbox formats all servers and MUAs can read and so several webmail packages are able to support filtering from the web interface quite simply - they just write a user's .procmailrc for them and, assuming the MTA uses procmail to deliver, bingo. And since their MUA and IMAP server will be reading mailboxes from the same structure, that one change affects all their mail. With a few modifications to popular Open Source webmail packages, we can hope for a similar opportunity for Mercury using IMAP. Perhaps Sieve would be a good choice of language for such filter files.
Cheers,
Sabahattin
David Harris writes:
> Let's be fair here: it's not that Mercury doesn't have filtering support - it's that IMAP doesn't have filtering support. Mercury has so much > filtering overall that you could practically sort sand with it. I could easily enough add filtering into the IMAP equation, but there would > be no standard way of manipulating the filters, and no way of having IMAP clients apply the filters on demand; it would all have to be > automatic and rather ad-hoc.
One thing your filtering system won't allow just yet is per-user-specified filters for mail delivered into a specific user's mailbox to be routed to subfolders. That's an essential first step, of course. There can be no GUI; it'll have to be a file dropped in the user's mail directory. A user can update that file to get mail sorted into the proper physical subfolders in their maildrop and observe the benefits in Pegasus Mail, with IMAP or with webmail using IMAP.
I still maintain that doing the filtering on the server automatically is the proper and correct thing to do. Letting clients do it using IMAP is just slow and 'orrible. Letting clients touch the filtering rules in standard filtering language form (Sieve from the IETF, for instance) is a nice idea, except of course that there's no way to do it over the network presently and Sieve still finds greatest usage between cooperating processes on the same box (EG: mail delivery agent / webmail facility). The greatest weakness in a Mercury-backended webmail is that it has IMAP as an exclusive abstraction for Webmail rather than file-based access to filter files and mailboxes, neither of which are really open.
Right now, the Unix world gets the benefit of, for instance, procmail or maildrop (and most recently Sieve's) prevalent usage by most MTAs for mail delivery, both of which support mailbox formats all servers and MUAs can read and so several webmail packages are able to support filtering from the web interface quite simply - they just write a user's .procmailrc for them and, assuming the MTA uses procmail to deliver, bingo. And since their MUA and IMAP server will be reading mailboxes from the same structure, that one change affects all their mail. With a few modifications to popular Open Source webmail packages, we can hope for a similar opportunity for Mercury using IMAP. Perhaps Sieve would be a good choice of language for such filter files.
Cheers,
Sabahattin