| Summary | enabling of vacation option without specifying a date causes mail loss |
| Queue | Ingo |
| Queue Version | 1.2.1 |
| Type | Bug |
| State | No Feedback |
| Priority | 2. Medium |
| Owners | |
| Requester | jas (at) cse (dot) yorku (dot) ca |
| Created | 12/10/2009 (5726 days ago) |
| Due | |
| Updated | 04/28/2010 (5587 days ago) |
| Assigned | 12/12/2009 (5724 days ago) |
| Resolved | 02/04/2010 (5670 days ago) |
| Github Issue Link | |
| Github Pull Request | |
| Milestone | |
| Patch | No |
would be appreciated.
Priority ⇒ 2. Medium
Type ⇒ Bug
Summary ⇒ enabling of vacation option without specifying a date causes mail loss
Queue ⇒ Ingo
Milestone ⇒
Patch ⇒ No
State ⇒ Unconfirmed
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.