Michael Haardt writes:
> The idea of a folder property versus a message property is
> interesting, but indeed I thought about a folder property to be
> specified by Sieve. Expiring mails on delivery is way more efficient
> than daily jobs, because on many systems (e.g. maildir) the folder
> contents are already in the page cache. Sieve, as MDA filter,
> controls local delivery on my systems and if local delivery includes
> expiration, it feels natural to control that, too.
Sieve, as a language/protocol, must be held to stricter standards than
any single implementation.
I agree 100%
If sieve makes the promise that a a mailbox should contain only the past
seven days' mail, users might reasonably rely on that. If, then, no
mail is delivered in seven days, the mailbox should STILL contain the
past seven days' mail (that is, it should be empty). If expiry happens
as part of delivery, older mail will still be retrievable.
I guess I have no problem per se with having per-folder or per-mailbox
expirations. But sieve operates per-message, not per-folder or per-mailbox.
Supporting per-message expirations is considerably more difficult than
per-folder or per-mailbox, and I doubt if the benefits are worth the cost.
But regardless of the expiration model, this proposal seems to me to be
putting the cart before the horse - we'd need to define an IMAP expiration
extension before it is reasonable to extend sieve to support it. And such a
sieve extension only makes sense if the model chosen for expirations is
per-message.
If your implementation confuses delivery and expiry, that's okay. You
have a privacy/security issue, that's all. But if the sieve language
confuses them, all implementations do. Much worse.
FWIW, I also don't like the idea of sieve managing folder properties.
That seems to be out of scope for sieve.
Exactly right. If the expiration model is per-folder or per-mailbox sieve
has no business trying to muck with it.
Ned