Changes have been made in Git for this ticket:

MFB: Fix procmail vacation rule (micha@kovoks.nl, Bug #7052).

http://git.horde.org/diff.php/ingo/docs/CHANGES?rt=horde-git&r1=ae3dfa4f32a99ebaff33773bd40b822903867de8&r2=19e4902b7388356321c589fd133a66046649fd52
http://git.horde.org/diff.php/ingo/lib/Script/Procmail.php?rt=horde-git&r1=9b22223f642b6ab65a71694ff34f709f06dfce9d&r2=19e4902b7388356321c589fd133a66046649fd52

Changes have been made in Git for this ticket:

MFB: Fix procmail vacation rule (micha@kovoks.nl, Bug #7052).

http://git.horde.org/diff.php/ingo/docs/CHANGES?rt=horde-hatchery&r1=ae3dfa4f32a99ebaff33773bd40b822903867de8&r2=19e4902b7388356321c589fd133a66046649fd52
http://git.horde.org/diff.php/ingo/lib/Script/Procmail.php?rt=horde-hatchery&r1=9b22223f642b6ab65a71694ff34f709f06dfce9d&r2=19e4902b7388356321c589fd133a66046649fd52

Great! Committed, many thanks!
Yes, known problem, see bug #8561.

Changes have been made in CVS for this ticket:

Fix procmail vacation rule (micha@kovoks.nl, Bug #7052).
http://cvs.horde.org/diff.php/ingo/docs/CHANGES?rt=horde&r1=1.55.2.127&r2=1.55.2.128&ty=u
http://cvs.horde.org/diff.php/ingo/lib/Script/procmail.php?rt=horde&r1=1.46.10.32&r2=1.46.10.33&ty=u

Luckily the patch applies without any problems on

$Horde: ingo/lib/Script/procmail.php,v 1.46.10.31 2008/11/07 16:53:43 
chuck Exp $



Btw. It's not easy to go to the FRAMEWORK_3 branche on http://cvs.horde.org/

This is from an abandoned branch (see 1st.README). Either use the 
latest version from Git, or from the FRAMEWORK_3 CVS branch.

$Horde: ingo/lib/Script/procmail.php,v 1.100 2008/11/07 06:28:03 chuck Exp $

1.100 of what?

After enjoying my vacation, here is (finally) a patch against 1.100

Have you made any progress yet?

I'll rewrite it for cvs then. Will take a day of two probably

No, that's the patch I was trying.

The ingofix2.diff does apply I hope?

The patch doesn't apply to procmail.php.

Not at all, I was just trying to say why it to longer to react to your 
request. I just mean to say:

1. I've fixed some issues, please import these. I think they will 
solve several issues.



2. I will not test this specific case (#7052) so if the o.p. doesn't 
react please close this case and let's go on to other issues.

So you are *not* longer interested in maintaining those drivers? Is 
that what you are saying?

Hmm, maybe a long way to say, please use my patches and close this case.

Uhm, what does this have to with our questions?

Sorry, you haven't heared from me, but i've became a father for the 
second time ;-) We still use my patch on several customer servers 
without problems. I'm unable to try it on CentoOS3 and I can't be 
botherd to install such an old version of CentOS, sorry.

Ping (once again)?

That would be great indeed - how do you want to handle this? Submit 
patches, or commit access, or?



Thanks!

That would be great. We desperately need dedicated maintainers for 
those drivers.

I've provided patches which we have been testing for a lot of our 
customers. If you dont mind,we would like to take over maintainership 
for this part of horde.

Giving up. With the current support for the maildrop and procmail 
drivers, we should consider dropping them.

Ping?

Volker, Eric, does this patch work for you?

There was more wrong with the procmail vacation script that was 
produced. Put some time in it and came up with the following diff. I 
think the resulting script is also easier to read

The

:0

/dev/null



surely breaks things in lenny. The patch we use and seems to solve 
most problems is attached. The {'s shouldn't start a new copy at all 
reading the documentation:





{      Followed by at least one space, tab or newline will mark the 
start of a nesting block.  Everything up  till  the  next closing   
brace  will depend on the conditions specified for this recipe.   
Unlimited nesting is permitted.  The closing brace exists merely to 
delimit the block, it will not cause procmail to terminate in any way. 
  If the end of  a  block is  reached  processing will continue as 
usual after the block.  On a nesting block, the flags ‘H’ and ‘B’ only 
affect the conditions leading up to the block, the flags ‘h’ and ‘b’ 
have no effect whatsoever.

Can anybody using Procmail provide a working and compatible solution 
for this issue?

Hi,



the procmail vacation script isn't working in the new ingo release (1.2.1).



It seems that the new /dev/null method breaks the script entirely: No

vacation message is being sent and, even worse, incoming mails are not 
being delivered to

the Inbox anymore. Seems they are copied to /dev/null!



When commenting these lines



:0

/dev/null



the script works fine again.



Seems that this fix has never been tested against other operating 
systems than Centos 3.



I'm using standard packages on a Debian etch machine.



Bye



Volker

Committed and merged, in absence of any feedback, thanks.

Changes have been made in CVS for this ticket:

http://cvs.horde.org/diff.php/ingo/lib/Script/procmail.php?r1=1.98&r2=1.99&ty=u

Try this.

This patch doesn't apply to CVS HEAD.

Ping?

I went with the /dev/null method for now.  Can you try this out?

We're seeing double-delivery because the {}'s are causing procmail to 
fork another copy and we get a delivery at the end of both }.  We 
either need to deliver the inner } to /dev/null, which looks weird, or 
we eliminate the inner {}.  Which method is preferred?

Matt, can you please review this ticket?

Can you post procmail debug logs for the first and second messages 
with clean databases.

A very quick check seems to indicate this change is better but still 
not right.  I regenerated the .procmailrc

script with the change, emptied the .vacation.* database, then sent 
two messages from myself to the user.



  First message triggered an auto-response which I got fine, second 
didn't.  That is as expected.  But

the user (with the .procmailrc)  received  duplicate copies of each message...



Maybe there is something specific to my site causing the duplication, 
I don't know.  But I do prefer it with

this change, than without.  Since I'd rather have them get a duplicate 
of everything, than have no vacation

reply sent out.



But either something else in my setup isn't right (causing the 
duplicate), or something else in this script isn't

right (causing the duplicate).



I'll try to investigate more later, and post more when/if I figure out 
what is going on...

Changes have been made in CVS for this ticket:

http://cvs.horde.org/diff.php/ingo/lib/Script/procmail.php?r1=1.97&r2=1.98&ty=u

http://www.stimpy.net/procmail/tutorial/vacation.html suggests that we 
should be using Whc:.  Can you try that?

Can you attach the generated procmailrc?  Or email me privately if it 
has sensitive info?

Centos (RHEL) 3.x, sendmail 8.12.11-4.RHEL3.6, procmail 
3.22-10.el3.centos.0 (e.g., a stock Centos 3.9

Final machine).



User has setup a vacation message via ingo using the procmail driver, 
and using a time period.  (I have not

tested without the time period; should try that sometime).



Using the stock vacation procmail recipe, it sends no vacation 
messages.  The message is delieved

normally to the recipient.  The procmail log shows:



procmail: Executing "formail,-rD,8192,/u1/demkov/.vacation.demkov"

procmail: Non-zero exitcode (1) from "formail"

procmail: Rescue of unfiltered data succeeded

procmail: Non-zero exitcode (-11) from "procmail"



If I change the recipe from using "0: Whaf" to use "0: Wha" then the 
vacation message is sent properly, but

the recipient gets two copies of the message in their inbox.  This is 
preferable to not sending a vacation

message, but still not good...



I tried using Whafi, but it didn't seem to help (still got the errors 
shown above).



Any ideas what is wrong?