formail, and any other program, may indeed be correct to treat email with this '>From ' header in it in this manner, but that is not the point.
The point is that delivery with 'procmail -d <user>' inserts that very
header in the first place.
As for 'From ...' headers. That's the mbox format. A line which
begins 'From ...' delimits each message in an mbox format file. I don't
recall if a blank line (so "\n\n") is necessary before this.
Perhaps you should understand mbox format before you comment further.
The testing I did, which I simplified the results of was to put a
quick recipe at the very start of my .procmailrc to spit out a copy of
the email as it was at that point. This already had the '>From ...'
header in it and I now know exim wasn't responsible for this as I've
since changed its config to not use -d with procmail and now the header
no longer appears. I also at this point had VERBOSE=yes in my .procmailrc.
I then took the file this first recipe produced and by hand fed it
through any other filter it would have hit. First spamassassin, then
bogofilter, then the formail recipe. I saved each stage of this.
THAT is what I was describing in my original addition to this bug
report.
Note that the procmail manpage says:
-d recipient ...
This turns on explicit delivery mode, delivery will be to the
...
When in explicit delivery mode, procmail will generate a leading `From
' line if none is present. If one is already present procmail will
leave it intact. If procmail is not invoked with one of the following
user or group ids : root, daemon, uucp, mail, x400, network, list,
slist, lists or news, but still has to generate or accept a new `From '
line, it will generate an additional `>From ' line to help distinguish
fake mails.
It's that very last described behaviour which is the bug. That
'escaping' with a > before 'From' is what is used in the *BODY* of an
email if it begins with 'From', so as to not falsely think the email has
finished and move onto the next. This is NOT what should happen in the
headers.
Look at the code in from.c in the procmail source, the makeFrom()
function. It uses FAKE_FIELD, which is defined to ">From ". So if
Debian wanted to fix this problem locally all it needs is that changing
to "X-Procmail-From: " or somesuch.
-Ath
--
- Athanasius = Athanasius(at)miggy.org / http://www.miggy.org/
Finger athan(at)fysh.org for PGP key
"And it's me who is my enemy. Me who beats me up.
Me who makes the monsters. Me who strips my confidence." Paula Cole - ME
signature.asc
Description: Digital signature
