This scenario, and ones like it, has been discussed here
before. I've got something working, so am posting details
{in case it's useful, so you can tell me I'm an idiot:-)}.
The 'vacation' bit of sieve wasn't working, because it kept
seeing a useless 'deliver'-created Return-Path: header.
I was starting procmail from sendmail, with a procmail
recipe something like this:
# *OLD*
CYUSER=$1
# Run spamassassin:
:0fw
| /our/bin/spamassassin -x -p /etc/mail/spamassassin.config
# All the mail that falls through to this point
# will be delivered into the user's INBOX
:0w:$CYUSER.lock
| $DELIVER -a $CYUSER $CYUSER
# If that fails, report back whatever $DELIVER said:
EXITCODE=$?
:0
/dev/null
# end *OLD*
This worked fine, except for sieve vacation. Why?
'deliver' would run and insist on tossing in a "Return-Path:
[EMAIL PROTECTED]", even though there was a perfectly
good Return-Path: already in the message. (Result: two
Return-Path:s) Of course, then sieve would send all vacation
messages to '[EMAIL PROTECTED]', who didn't appreciate
them.
I couldn't see a way 'round it except to fish out the
pre-existing Return-Path: and force 'deliver's hand (with
-r). So I now have:
# *NEW*
CYUSER=$1
# snag the existing Return-Path:
RPTMP=`/usr/bin/formail -xReturn-Path: | /bin/sed -e 's/^ *<//' -e 's/>$//'`
RETPATH=${RPTMP:-badbadbad}
# Run spamassassin:
:0fw
| /our/bin/spamassassin -P -x -F 0 -p /etc/mail/spamassassin.config
# All the mail that falls through to this point
# will be delivered into the user's INBOX
:0w:$CYUSER.lock
* ! RETPATH ?? badbadbad
| $DELIVER -a $CYUSER -r "$RETPATH" $CYUSER
# if we get here, something bad happened re the Return-Path:
:0w:$CYUSER.lock
| $DELIVER -a $CYUSER $CYUSER
# If that fails, report back whatever $DELIVER said:
EXITCODE=$?
:0
/dev/null
# end *NEW*
As best I can tell, this is vacation'ing happily. I would
be grateful for any improvements that you may suggest.
Regards,
Will
