[Tickets #8766] enabling of vacation option without specifying a date causes mail loss

bugs at horde.org bugs at horde.org
Thu Dec 10 21:37:01 UTC 2009


DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/8766
------------------------------------------------------------------------------
  Ticket             | 8766
  Created By         | jas at cse.yorku.ca
  Summary            | enabling of vacation option without specifying a date
                     | causes mail loss
  Queue              | Ingo
  Version            | 1.2.1
  Type               | Bug
  State              | Unconfirmed
  Priority           | 2. Medium
  Milestone          |
  Patch              |
  Owners             |
------------------------------------------------------------------------------


jas at cse.yorku.ca (2009-12-10 16:37) wrote:

If a user enables the vacation option, and doesn't enter a start and  
end date, my expected behaviour of vacation would be to stay enabled  
until the user disables it.  Instead, while the system does auto-reply  
with the users vacation message, the received message goes to /dev/null.

There were other fixes applied to procmail in 1.2.2 and I'm concerned  
about upgrading because I know that procmail support isn't a high  
priority, our users aren't complaining about other functionality at  
this time, and I don't want to effect that by going to 1.2.2 where  
problems have been reported.   If anyone could try this with 1.2.2 and  
let me know if it works, it would be appreciated.

Without date the .procmailrc contains:

:0
{
  --stuff that doesn't matter--
.
.
.
   :0 Whc: ${VACATION_DIR:-.}/vacation.lock

-- more stuff that I don't think matters ---

   :0
   /dev/null
}

With date:

:0
{
   --stuff that doesn't matter---
.
.
.
  :0 Whc: ${VACATION_DIR:-.}/vacation.lock
   * ? test $DATE -gt $START && test $END -gt $DATE
   {  :0 Whc
.
.
.
   :0
   /dev/null
  }
}

In the non-date case, the message is delivered to /dev/null which is  
verified by looking at procmail logs.







More information about the bugs mailing list