Alright, it's all committed. Thanks!

oops, those were testing values that get overwritten once you actually 
do something with the script. i just used them as i started coding on 
the backend.. they no longer serve any purpose and can safely be 
replaced with ''.

I've got this just about cleaned up and ready to be committed, but 
what are the hardcode timestamp and year/month/day values supposed to 
be in the Sieve_Action_Vacation constructor?

right, cleaned up the whole list of $vars->get now.

See feedback from personal mail.

okay, stuff is cleaned up a bit now, the Horde-Date thing definately 
improves things! (wish i'd noticed that one earlier instead of 
re-inventing the wheel). thanks for the feedback.

Btw, please only worry about the HEAD version for these cleanups - 
it'll all get merged to stable from HEAD later, and the bounty will be 
complete once it's in HEAD. You can maintain the stable patch for the 
requester separately if you/they want though, of course.

I'm ready to commit this patch if it's cleaned up a bit. First, please 
have a look through horde/docs/CODING_STANDARDS. Second, you can use 
Horde_Form much better in a few places - for instance, it'd be much 
nicer to have a Horde_Date object for the start/end times, and to set 
it with a monthdayyear Horde_Form type (with a pop-up date picker), 
rather than the multiple accessors for year/month/day you currently 
have.



- you should use $form->getInfo() so that you're not accessing $vars 
directly to get the submitted values



- use PHP features, like using strtotime('-1 day') rather than 
subtracting a fixed number of seconds from time(). Also on that line 
you can do $start = $end = ...



- no need to assign the result of $form->addVariable(...) to a 
variable unless you're actually going to do something with it.



There might be a few other things but that should be most of it. Thanks!

Great, keep us all updated!

So far it looks very good. We have not tested the functionality in 
real life yet, though.

Any feedback yet from the requester? Also, I'm very interested to see 
the global cron stuff.



Thanks!

I tested the patch on MacOS X 10.4 Server and it works.

and a somewhat cleaned up patch for cvs, with functional procmail



not that the sieve script can be cleaned up quite a lot once the date 
extension to sieve

(http://tools.ietf.org/html/draft-freed-sieve-date-index-00) is 
commonly implemented.

fixed another bug in the sieve script.

sieve on OS X didn't like my regexps, so here's a new patch for h3-1.1.2

new patches for cvs fill follow, some more tidying up can be done there.

I'm working for few days now an a more generic CRON fuction for Horde. 
Actually I'm about to provide a cron backend that can run tasks on 
schedule. A script must be called by the CRON, and then a kind of 
internal cron system is running to get tasks that must be executed.



Up to now, I'have focused my efforts on making the backend working. 
There is a class to can add/store/delete a job (thanks to the datatree 
system). And the other side, there is a script that checks all tasks 
and executes those that need to be.



I'm planning to implement pretty soon, the first real application with 
Ingo. Vacation is a godd idea, but I was thinking enabling this 
functionnality for each rule, because, it's can be nice to redirect 
your office-mail on your home-mail by the evening, or the week-end. 
You can also change your spam filtering configuration during day and 
the night.



I think that implementing a generic CRON backend will be much more 
usefull than simply answering your bounty. I'm thinking about imp and 
it's maintenance tasks that could executed automatically... The main 
problem for all this is the authentication... I'm not be sur being 
able to handle this problem in all cases (authencation with third app 
w/o Admin password, for example...)



Best regards

and a patchfile for CVS, although procmail seems totally broken

These patches to ingo-h3-1.1.2 implement a filter rule for spam and 
timed vacation without the need for an external cron script. This 
works for both procmail and sieve.

I have added this is a bounty, please use the bounty page for sponsoring.

We're aware of these potential problems but do not think that they are 
major. In fact we have very good experience with a different mail 
server system that offers timed vacation functionality. It was 
introduced because 90% of the users forgot about deactivating the 
notice after they come back to work. The users love the feature too, 
because they don't need to go through the process twice, once for 
enabling and once for disabling the notice.



The crontab problem is not really an issue because a proper server 
installation is always a prerequisite for proper operations. And of 
course, users can always opt to not change the notice automatically by 
leaving the start and end dates empty.

I'm still not sure if this is really a good idea, because it could 
cause all kind of problems. The UI can't know whether the cronjob is 
really enabled for example. So people would use that feature but it's 
never working. Or people have chosen to not automatically activate 
their changed rules. The cronjob would still do that without their 
interception.

You are right. We need this functionality in Ingo. I mixed that up 
with the vacation functionality inside Ingo.
You mean that a single "cyrus" user with global admin privileges is 
required? That would be fine.

Are you sure you want this in the Vacation module? The Sieve support 
that you mention exists only in Ingo.

Beside that, please that this is only possible on backends that create 
and activate rules by means of a single administration user.

You're invited to add this to your list of bounties. If you'd like to 
add our logo, I have it attached.

equinux is sponsoring a bounty of US 200$ for implementing the 
following enhancements to the vacation module:



- timed vacation messages: the UI should have date fields for begin 
and end of the vacation message, the implementation could be possible 
via two cron jobs running at 23:59 and 0:00 the first for disabling 
vacation msgs at the end date and the second for enabling at the start 
date.

- support to suppress vacation replies when the message is tagged as 
spam: This could be implemented easily by adding 'header :contains 
["X-Spam-Flag"] "YES"' to the sieve condition. The mentioned header is 
standard for amavisd(-new) which is very widespread and a lot of other 
Spam filter systems. Of course, a configuration option to configure 
the exact Spam-Header would be nice.