Maynard Brandt had written,
| There is nothing in my $PMDIR/rc.maillists that should have sent that to
| /dev/null. Is there anything in procmail that would have triggered that
| destination?
He wrote back to me, explaining the problem: there was a recipe that trashed
mail to /dev/null, but it tested for a subject line that was different from
the one recorded in the logabstract. Since the message itself was deleted,
he couldn't look at it; his only information about it was the logabstract.
But he was able to receive (or unable to prevent receiving) another like it.
It turned out to have TWO subject lines. The earlier one was recorded in
the logabstract, but the later one matched the recipe that dumped the message
to /dev/null.
I complimented him on his sleuthing and suggested this in case of similar
problems in the future:
:0
* ^Subject:.*$(.+$)*Subject:
{ TRAP="${TRAP:+$TRAP ; }formail -XSubject:" }
Those a little put off by or unfamiliar with the sh construct there may
find this more legible:
:0
* ^Subject:.*$(.+$)*Subject:
{
:0 # if there already is a trap set, add this
* TRAP ?? .
{ TRAP="$TRAP ; formail -XSubject:" }
:0E # if there wasn't a trap before
{ TRAP=formail -XSubject: }
}
Anyhow, the purpose would be to list all subject lines in the logfile upon
exit if there are two or more. The earliest would appear twice: once in the
trap output and once in the logabstract. If there are exactly two, that
could be prevented with formail's -U option, but if there are three or more,
we don't want to do that.
Hmm...
:0
* ^Subject:.*$(.+$)*Subject:
{ TRAP="${TRAP:-: ; }formail -XSubject:" }
Nah, that would force a shell for the trap even if the formail call were the
only thing in it.
All told, the only thing wrong with procmail was the selection of the first
subject line for the logabstract instead of its including both (or all if
there are three or more).