I want to execute a formail and sendmail 2 times for the same match
:0
* ^Subject:.rapport 2
{
:0f
{
| formail -I "To: x@xxx.com" | /usr/sbin/sendmail -oi x@xxx.com
}
:0f
{
| formail -I "To: y@xxx.com" | /usr/sbin/sendmail -oi y@xxx.com
}
}
But this is just skipping it all?
any idea
progressdll wrote:
> I want to execute a formail and sendmail 2 times for the same match
>
> :0
> * ^Subject:.rapport 2
> {
> :0f
> {
> | formail -I "To: x@xxx.com" | /usr/sbin/sendmail -oi x@xxx.com
> }
> :0f
> {
> | formail -I "To: y@xxx.com" | /usr/sbin/sendmail -oi y@xxx.com
> }
> }
>
> But this is just skipping it all?
> any idea
>
Suggested correction(s) to your recipe:
# Note, you may need to adjust this path for your system
# procmail normally defines the SENDMAIL variable internally, so you
# probably don't need to modify it, however in order to use some of the
# sendmail command line flags, you might need to define it anyway. Try
# it without first
SENDMAIL=/usr/sbin/sendmail
# Execute the following procmail nested recipe if the
# Subject pattern matches.
:0
* ^Subject:.rapport 2
{
# Replace the To: header line, then Cc: the message to the new
# recipient
# Note: The "c" flag here spawns a copy of the message so the original,
# unaltered message in the main procmail data pipe will not be lost.
# Only the copy of the message will have the To: header replaced in
# this case.
:0 c
| formail -I "To: x@example.com" |$SENDMAIL -oi -t
# Replace the To: header line again, then Cc: the message to the new
# recipient
:0 c
| formail -I "To: y@example.com" |$SENDMAIL -oi -t
}
....
# Deliver the unaltered message to inbox
:0
$DEFAULT
suggested reading if you haven't already done so:
man procmail
man procmailrc
man procmailsc
man procmailex
--
Garen
Garen Erdoisa wrote:
> progressdll wrote:
>> I want to execute a formail and sendmail 2 times for the same match
>> [snip]
> Suggested correction(s) to your recipe:
> [snip]
On further thought, you'll probably want to delete the Cc: header also
unless you know for a fact that the mail is from a daemon and will never
have a Cc: header, otherwise this particular style of replace the To:
header and send on will also re-send a copy to any addresses in a Cc:
header as well.
:0 c
| formail -I "To: x@example.com" -I "Cc:" |$SENDMAIL -oi -t
Depending on the situation a better solution would be to do surgery on a
copy of the message before forwarding it on:
* delete the Cc: header
* extract the envelope sender address and save it in an X-header
* substitute a local return path address as the envelope sender
* etc.
Then forward the message using Bcc:
The following is an example that might work for a mini listmail situation:
# This example recipe presumes you are running it out of a
# ${HOME}/.procmailrc and not out of /etc/procmailrc which requires
# other considerations.
FORMAIL=formail
# Define a log file for procmail to send it's log messages
LOG=${HOME}/procmail.log
# Define a newline character for use in procmail LOG entries
NL="
"
# Define a variable with this email address for use
# in Reply-to: headers etc.
MYEMAIL="${LOGNAME}@${HOST}"
BCCTO="x@example.com, y@example.com"
# Fork off a copy of the procmail data pipe then do surgery on the copy,
# provided the Subject: header contains a matching string and there is
# no X-loop header found, then forward the message
:0c
* ^Subject:.something
* ! ^X-Loop:
{
# Extract the envelope sender address and save it in an X- header
# so that the information is not lost or overwritten
# In this recipe the MATCH variable will capture everything to the
# right of the "\/" string below. This is unique to procmail regular
# expressions.
# The sed edit will strip everything to the right of the email address
# to the end of the line. Usually this is just a date stamp.
:0
* From \/.*
{
RETURNPATH=`echo "${MATCH}" |sed -e 's/ .*$//'`
# save a copy of this information in the procmail log
# which may be useful for debugging
LOG="[$$]$_: RETURNPATH=${RETURNPATH}${NL}"
}
# capture the Message-ID: string(s)
REFERENCES=`${FORMAIL} -cx "Message-ID:"`
# use formail to do surgery on the headers. This will preserve
# the From: header and any other header information. It will
# also replace the To: header and delete any Cc: header.
# basically it has your server assuming responsibility for
# resending the message and preserves certain tracking information
# which is useful for tracing purposes if something goes wrong.
:0 f
| ${FORMAIL} -I "Reply-To: ${MYEMAIL}" \
-I "References:${REFERENCES}" \
-I "In-Reply-To:${REFERENCES}" \
-I "To: ${MYEMAIL}" \
-I "Cc:" \
-I "Bcc: ${BCCTO}" \
-A "X-Loop: ${MYEMAIL}" \
-A "X-Original-Return-Path: ${RETURNPATH}"
# Send the reconstructed message
:0 Wic
| $SENDMAIL -oi -t
# Save the return code from the last command executed
RET=$?
# If the last recipe was successful, also do the following
:0 a
{
LOG="[$$]$_: Sucessfull delivery to list${NL}"
LOGABSTRACT=no
:0
/dev/null
}
# Else, the message failed to ship, save it in an errors folder
# or possibly do something else here to handle the error condition
# such as queue it for future delivery or something.
:0 E
{
LOG="[$$]$_: Sendmail failure - Return code = ${RET}${NL}"
# File the reconstructed copy in the errors folder
:0:
${MAILDIR}/errors
}
}
# else
# file the local copy in /dev/null if the X-Loop header is present
# Note: the tests begin with a "$" so that the variables will be
# expanded before being evaluated as a procmail regular expression.
# Also the procmail special form of the $\MYEMAIL variable will expand
# to something like
#
# ()myname@example\.com
#
# before it's evaluated as a regular expression. This savs you the
# trouble of having to escape meta characters used in procmail regular
# expressions in what is intended to be a literal string.
# You can see this expansion in the logfile if you turn on verbose
# logging. ie: VERBOSE=yes
:0 E
* $ ^To: $\MYEMAIL
* $ ^X-Loop: $\MYEMAIL
{
LOG="[$$]$_: Filed local copy of resent message in /dev/null ${NL}"
LOGABSTRACT=no
:0
/dev/null
}
....
# Save to default inbox
:0:
$DEFAULT
That was more long winded than I really wanted to get, but I hope it
helps with understanding some of the issues at least with forwarding
messages to systems that are external to your own.
A lot of the forwarding style you select really depends on if you are
forwarding to systems external to your own, or doing internal forwarding
for administrative purposes. If the latter, you can make it a lot
simpler since you control both the sender and receiver mailboxes and can
punch holes in your internal forwarding that otherwise might be blocked.
In the case of internal forwarding something as simple as this probably
work just fine:
:0c
! x@example.com, y@example.com
....
:0
$DEFAULT
--
Garen