procmail
[Top] [All Lists]

Re: procmail inserting blank line in headers

1999-01-16 11:41:00
I have a feeling that whatever is going on here will end up being
explained by confusion between various mail software regarding
carriage return (ASCII 13 decimal) and line-feed (ASCII 10 decimal)
characters and pairs of them (CRLF) which end lines during mail
transport (but are stored as just LF in typical UNIX mailboxes).

It may be a good idea to view "before" and "after" instances of
the mail using a command such as "od -c" and look for "\r" or 012,
and "\n" in the result.

At 09:34 AM 1/16/99 -0500, *selah* wrote:

[snip conversations on X-Status]
There might be something that gets removed from Pine's idea of headers
by the empty line which makes it feel it has to add X-Status to those
messages. Would there e.g. happen to be a Status: header or something
in among the dropped headers?

It seems that maybe it's the >From header that sets it off. It has been
inserting a blank line after X-UIDL as well as X-STATUS. This is one of
the headers:

We normally sloppily refer to "From " or From_ 'headers' on this list
but in reality they are not mail headers (headerfields) per RFC822.  Think of
them as mailbox message separators added when storing mail... there has to be
*some* way to tell what goes with what message, and that's a sort of
"de facto standard".  When you see ">From " it generally means that "From "
was spotted inside a mail message, and it has been 'escaped' to prevent
a false splitting of a message by a mail client later.

MDAs and mail clients must agree about what does or doesn't constitute
the mail message separator inside a mailbox or folder, and I suspect that
CR confusion will be found to have entered here.

From news(_at_)reader1(_dot_)reader(_dot_)news(_dot_)ozemail(_dot_)net  Sat 
Jan 16 08:28:16 1999
X-UIDL: e5ceb808a6a313bb2cf6253f33954ec6

I am suspicious already... where did the mail come from?  Various POP
mail handlers add X-UIDL to keep track of what's been POPped
and what hasn't.  Something has been here and left fingerprints.

From 65535  Sat Jan 16 08:28:16 1999

I wonder if that (65535) is the UNIX 'nobody' user number?

Return-Path: news(_at_)reader1(_dot_)reader(_dot_)news(_dot_)ozemail(_dot_)net

When systems store Return-Path, I've always seen it match what's in
the "From ".  Your first "From " matches Return-Path; this 65535 one
I'm betting is related to the X-UIDL.

Received: from nf1.netforward.com (nf1.netforward.com [204.57.67.27]) by 
tam.dorsai.org (8.8.4/8.6.12) with ESMTP id IAA03013 for 
<soma(_at_)dorsai(_dot_)org>; Sat, 16 Jan 1999 08:28:15 -0500 (EST)
[...]

I hope my comments shed more light than confusion, but I don't
really have any answers.  I suspect that you'll have to tell us
exactly what sequence of processes operate on your mail.  As far
as I know, neither sendmail (I infer sendmail from the 8.8.4/8.6.12)
nor procmail nor pine ever adds an X-UIDL headerfield.

Cheers,
Stan