procmail
[Top] [All Lists]

Re: Problem with arguments

1997-04-02 12:17:00
Manuel Mollar Villanueva <mollar(_at_)moon(_dot_)inf(_dot_)uji(_dot_)es> writes:
I have problems using the arguments passed to procmail by the caller.

I need to store in a unique mailbox all the mail that arrives for one domain,
and later, filter the mailbox using the destination address.

Using a rewriting rule of the form (sendmail.cf):

R$*<@domain.com.>$*    $:mailbox

is not adequate for my case because lot of mails (for example those that come
from a mailing list) does not contain a "To:" field, so the mailbox cannot be
re-filtered based on the destination address.

This is correct.  You've lost the envelope destination address(es) when
you do that.


I have decided to use the procmail mailer as defined in the procmail man pages:

      R$*<@domain.com.>$*     $#procmail $@/etc/procmailrcs/domain 
$:$1(_at_)domai
n.com.procmail$2
      R$*<@$*.procmail>$*     $1<@$2>$3       Already filtered, map back

If you're using a recent sendmail (and you should be), then you should
just use the mailertable, as you then don't need to hack the
sendmail.cf everytime you change the affected domains.  More
information on the mailertable can be found in the cf/README file in
the sendmail source tree.


with the mailer defined as (without the m Flag, of course):

      Mprocmail,      P=/usr/bin/procmail, F=cDFMShu,  S=11, R=21,
                      A=procmail -m $h $f $u

Then I want to use procmail to add a field, say X-To, including the $u 
parameter,
that is, the real destination address.

That is, the envelope recipient address(es).


But I cannot access the arguments inside the rcfile, so I cannot do it.
Which is the reason I cannot access them?
Is it due to a security problem?

The $<number> variables (e.g., $1) have to be expanded by procmail, not
the shell.  The following should work, for example:

        RECIPT = $2
        :0:
        |formail -I"X-Envelope-To: $RECIPT" >> /some/mailbox

If you tried to put $2 in the action instead of $RECIPT it wouldn't
work because that action is done via the shell, so procmail leaves the
variable expansion to it (the shell).  $2 is empty in the shell, and
thus you have an empty header.  The same effect will happen with any of
the pseudo-variables like $-, $=, $@, $_, etc.


I'll note that you don't have to remove the 'm' flag for this to work,
you just have to learn how to loop within procmail using recursive
INCLUDERCs.  For example, you could put in the file
/etc/procmailrcs/domain the following:

        # Pop and store the sender.  The rest of the args are recipients
        SENDER = $1
        SHIFT  = 1
        # Loop...
        INCLUDERC = $_.loop
        # If we fall out of the loop, exit without bouncing
        HOST

Then in /etc/procmailrcs/domain.loop put:

        # Pop the next recipient
        RECIPT = $1
        SHIFT  = 1
        # Add it to the comma separated list we're building.
        # Note that the line wraps with the characters plus, comma,
        # newline, tab, close brace.  This will cause the list we're
        # building to look like:
        #       foo,
        #       bar,
        #       baz
        LIST = "$RECIPT${LIST+,
                }$LIST"

        # Are there any more recipients?  If so, loop; otherwise if LIST
        # isn't empty then deliver a copy of /some/mailbox with the
        # appropriate headers.
        :0
        * $ $#^0
        { INCLUDERC = $_ }
        :0 E:
        * ! ${LIST:+!}
        |formail -I"From $SENDER" -I"Return-Path: $SENDER" \
                 -I"X-Envelope-To: $LIST" >>/some/mailbox


With some simple changes to the above "domain.loop" you can handle some
addresses in the given domain differently, say, by forwarding them
elsewhere or by delivering them to their own mailboxes, instead of
putting them in the list of recipients in the X-Envelope-To: header.


Philip Guenther