On Sat, 12 Oct 2002, Bart Schaefer wrote:
Procmail is expecting to get the messages with unix line termination, e.g.
just "\n" at the end of each line.
There's the explanation. The file I dumped with the perl filter had a
whole lot of ^M-s in it when I looked at it with less.
No, those are only in the middle of the continued Received: headers. Take
a look with emacs - ah! less is treating <cr><lf> pairs as line-ends,
emacs shows ^M at the end of every line through the entire header and
body, including the "blank" line that separates them.
(Remember, I stuck a perl script into the condition of my procmail recipe
and dumped its STDIN into a file so I could see what was being grepped in
the condition - that's the file that has the ^M-s in it.)
I thought RFC822, dating back to the days of Western Union TeleType
terminals, specified <cr><lf> as the line separater in e-mail. Am I just
wrong about that? Or is something expected to convert line-ends to unix
conventions before the message gets delivered?
I'm picking the mail up with fetchmail from an IMAP server on my ISP
(solaris the last time I had reason to know), I sent it there with pine
(linux) connecting to port 25 at the ISP, After whatever processing he
does, he used procmail as the local delivery agent and I ran it through a
big .procmailrc there, using only header recipes. (This e-mail list has a
big killfile, implemented with two recipes per kilt address.) I'm running
fetchmail on linux and there is no listener on port 25 here, at the
moment, so fetchmail is handing the message directly to procmail. If
they're not required by the protocol, who put those ^M-s in the message?
For that matter, those ^M-s are not in the mailbox files, so why does the
procmail delivery agent strip them after screening the message instead of
stripping them before screening the message?
If it is instead getting lines with dos/windows termination "\r\n", it
will think the entire message is the header, because it will never find
the sequence "\n\n" which means end of header/start of body.
Thank-you, Bart. You identified exactly what is happening. I wonder how
many years it would have taken me to solve that one.
Clearly, I am in business with ":0 HB:", but where are the ^M-s coming
from and where should they be removed?
dan
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail