1

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

SENDMAIL=/opt/zimbra/postfix/sbin/sendmail
SHELL=/bin/sh
PATH=$HOME/bin:/usr/bin:/bin:.
MAILDIR=/opt/zimbra/procmail/
DEFAULT=$MAILDIR
LOGFILE=.procmaillog
LOCKFILE=.procmaillock
VERBOSE=yes

#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 }'`


LOCALPART=${FAXNO_}
DOMAIN=faxservice.com

# Forward the email
:0
! ${LOCALPART}@${DOMAIN}

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

PROBLEM

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

TRIED SOLUTIONS

  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
:0
* ^Return-Path:[   ]*\/[^  ].+
{ env=$MATCH }
:0
! ${env+-f "$env"}
! ${LOCALPART}@${DOMAIN}

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

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

QUESTIONS

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.

Community
  • 1
joshu
  • 771
  • 3
  • 12
  • 28
  • 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 02 '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 02 '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 02 '13 at 13:23

1 Answers1

0

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 muck with SENDMAIL?
SENDMAIL=/opt/zimbra/postfix/sbin/sendmail
SHELL=/bin/sh
# Don't muck with PATH
#PATH=$HOME/bin:/usr/bin:/bin:.
MAILDIR=/opt/zimbra/procmail/
# Don't muck with DEFAULT
#DEFAULT=$MAILDIR
LOGFILE=.procmaillog
VERBOSE=yes

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

# Forward the email
:0  # note: whitespace is [ space tab ] and [ ^ space tab ]
* ^Return-Path:[    ]*\/[^  ].+
{ env=$MATCH }
:0
! ${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.

(ServerFault's Markdown renderer will replace tabs with spaces, so you can't entirely correctly copy/paste this. The requirement to include the tab in the whitespace is a corner case so for quick testing this is probably unimportant.)

tripleee
  • 1,324
  • 3
  • 14
  • 24
  • Is it possible that `env` could contain a double quote and escape the quotation of the `-f` flag? – Mikko Rantalainen May 26 '22 at 09:57
  • @MikkoRantalainen Thanks for the comment, but a quote in the variable's value should work fine, just like it does in the shell. I don't think that is a realistic concern, anyway (how would you get a double quote into the `Return-Path:` in the first place? IIRC SMTP requires quotes to be paired anyway). – tripleee May 27 '22 at 06:21
  • I was thinking about potential attacker guessing that you're forwarding post and forging any input possible to attack the host running procmail. And attacker could obviously try anything (including binary input) regardless of SMTP spec. I know that in `bash` shell the syntax `"$var"` would be safe but I don't know procmail well enough to know if it's safe here. – Mikko Rantalainen May 27 '22 at 09:02
  • It basically uses the shell to run `$SENDMAIL $SENDMAILOPTS` – tripleee May 27 '22 at 09:10