Re: Received: headers after From:

Excerpts from [procmail]: (06-Nov-97) Re: Received: headers after From: by 
David W Tamkin
> > Also, you need procmail version 3.11pre5 or higher or else procmail will
> > strip the newlines from the end of MATCHes.
> Yes, but echo will put the newlines back.
Um, no. It would put the last newline back, but all the other ones would
still be eaten. (There's only one `echo' in my solution.)

> Anyhow, I'm going to try this myself from scratch. If I come up with
> anything here, it's sure to have some resemblances to Ed's code, but
> it baffles me where he was going with his AFTERFROM counter. (Comments
> are sometimes a *good* thing.)
Sorry. It seemed obvious to me. Anyway, AFTERFROM is a flag, not a counter,
and is initialized to 0. The recursive INCLUDERC parses the header
line-by-line. When it reaches the first From: header, it sets the AFTERFROM
flag to 1. If a Received: header is encountered and AFTERFROM is either 1 or
2, then that header line is skipped and AFTERFROM is set to 2. After all
header lines have been parsed, control goes back to ~/.procmailrc. If
AFTERFROM is 2, then it replaces the header with $NEWHEADER using `echo'.

It's a shame you have to use `echo' to replace the header (or the body) with
the contents of some variable. I think it would be a nice feature if you
assign a string or a variable directly to the special variables H and B.
Hmmm. Maybe I'll e-mail that suggestion to Stephen.

> I'm also concerned about how well Ed's code handles continuation
> lines, which Received: headers tend to have. Procmail wraps them
> automatically when the search area is H (or above the first empty line
> if the search area is HB), but I think it does not for any other
> search area.
When the header is snarfed into $HEADERLINES via $MATCH, all headers are
unwrapped and they subsequently remain unwrapped in $HEADERLINES. So my
solution has the unfortunate side-effect of unwrapping all continued headers.
I hadn't thought of that before. Actually, your solution does this as well
since you also use $MATCH. I don't see any way of avoiding this. Do you?

> Here's a method with one formail and one shell but no recursion.
Very nice. It inspired me to implement a similar optimization to the
recursive INCLUDERC solution that cuts down considerably on the number of
recursions performed. It also makes the AFTERFROM flag completely
unnecessary.

In your .procmailrc, put the following:
#--------------------------------------------------------------------------
# Procmail 3.11pre5 or higher required for the following code.
# You might want to increase LINEBUF beyond the default size.
:0
* ^From:.*$(.+$)*Received:
* $ < ${LINEBUF}
* ^^\/(.+$)(([^F]|.[^r]|..[^o]|...[^m]|....[^:]).*$)*From:.*$
{
     NEWHEADER = $MATCH

     :0
     * $ ^^$\NEWHEADER\/(.+$)$^^
     {
          HEADERLINES = $MATCH
          INCLUDERC = received-after-from.rc

         :0fwhi
         | echo "$NEWHEADER"

     }
}
#--------------------------------------------------------------------------

Then, in the file received-after-from.rc:

#--------------------------------------------------------------------------
:0
* HEADERLINES ?? ^Received:
{
     :0
     * HEADERLINES ?? ^^(.*$)+\/(.*$)+
     { REMAININGLINES = $MATCH }

     :0E
     { REMAININGLINES }

     :0
     * HEADERLINES ?? ^^\/.*$
     { THISLINE = $MATCH }

     :0E
     { THISLINE }

     :0
     * THISLINE ?? ^Received:
     { THISLINE }

     NEWHEADER = "$NEWHEADER$THISLINE"

     # Now recurse if there are any remaining lines.
     :0
     * REMAININGLINES ?? .
     {
          HEADERLINES = $REMAININGLINES

          INCLUDERC = $_
     }
}

:0E
{ NEWHEADER = "$NEWHEADER$HEADERLINES" }
#--------------------------------------------------------------------------