Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

This is the first time using procmail and I've got the following recipe,


#Get the recipient's address
TO_=`formail -xTo: \
         | expand | sed -e 's/^[ ]*//g' -e 's/[ ]*$//g'`

#Get the recipient's local-part, e.g. fax number
FAXNO_=`echo "${TO_}" | awk -F@ '{ print $1 }'`


# Forward the email

The recipe gets the TO email header, parses it and builds the forwarding email address.


The problem with the recipe is that the email is rejected by the recipient because the Return-Path header is modified.


  1. I added the following to the top of the recipe,

    SENDMAILFLAGS="-oi -f \"$SENDER\""

    this makes the Return-Path header blank and the recipient still rejects the email.

  2. I found this serverfault question and modified my recipe as follows,

    # Forward the email
    * ^Return-Path:[   ]*\/[^  ].+
    { env=$MATCH }
    ! ${env+-f "$env"}

    procmail's log file shows an error that there is no match,

    procmail: No match on "^Return-Path:[   ]*\/[^  ].+"


I don't know whether to make a change to the postfix pipe,

   procmail-fax-send unix    -   n   n   -   -   pipe
   flags=    user=zimbra argv=/usr/bin/procmail  /opt/zimbra/procmail/procmailrc

Or how to change my recipe, so that the original sender is not modified after procmail processes the email.

share|improve this question
Using a global lock file with LOCKFILE=.procmaillock serves no useful purpose here, as far as I can discern. Running multiple Procmail instances should be safe unless (for example) you have replaced your real Sendmail with a hack of your own which tries to save something to a database with exclusive write access or something like that. – tripleee Apr 2 '13 at 12:36
You cannot have two actions, so the double exclamation marks in your edited recipe are a syntax error. If there isn't a Return-Path: header in the incoming message, then of course, you cannot extract it, so the error is never reached anyway. – tripleee Apr 2 '13 at 13:06
If SENDER is an acceptable envelope sender, just replace ${env+-f "$env"} with -f "$SENDER" and you're done (modulo the syntax error changes which will have to be undone, of course). – tripleee Apr 2 '13 at 13:23

Without attempting to address the Postfix part of the question, here is an attempt at fixing the Procmail problems and doing away with the multiple external processes just to extract the token before the @ sign in the To: address.

# Do you really need to much with SENDMAIL?
# Don't muck with PATH
# Don't muck with DEFAULT

# Get the local part of the recipient's address
:0  # note: whitespace is [ ^ space tab @ ]
* ^To:.*\<\/[^  <>@]+@
  * MATCH ?? ()\/[^@]+

# Forward the email
:0  # note: whitespace is [ space tab ] and [ ^ space tab ]
* ^Return-Path:[    ]*\/[^  ].+
{ env=$MATCH }
! ${env+-f "$env"} ${LOCALPART}@${DOMAIN}

If there is no Return-Path: header, the env assignment should end up empty, and the message should be forwarded with whatever envelope sender your Postfix generates.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.