On Thu, 12 July 09:36 Pawel Salek wrote:
On 2001-07-12 09:40 Brian Stafford wrote:
On Thu, 12 July 05:34 John Merryweather Cooper wrote:
Well, I'm using procmail 3.21 on FreeBSD 4.3-STABLE as a mailbox
filter for Balsa 1.14_2. Some of the time, things work great. But,
particularly with IE 5.x, Netscape, mutt, and Pine-originated
messages, I get a "+OK nnnn octests" (where nnnn is some number)
just
That is a POP 3 response line.
When the RETR command is issued the POP server responds with
+OK arbitrary text
message in RFC 2822 format
.
I suspect this may be a result of "\r\n"<->"\n" confusion on balsa's
side or something. I think it is not related to procmail, it just
filters the mail as it gets it.
/Pawel
response lines from a POP server should *always* be terminated with the
canonic CR-LF sequence. This applies to message content also, RFC 2822
(and 822 before it) state that only CR-LF is recognised as a line termination.
Assuming there is no problem with the pop client, this should never be
a problem. Procmail was designed for use with sendmail and therefore
expects \n terminations. Something has to do the translation and this
just isn't reliable because although RFC 2822 prohibits bare \r and \n in
messages, 822 permitted them within a line and only allowed CR-LF as
the termination. Clearly \n -> \r\n and \r\n -> \r\n cannot be reversed
correctly.
Unfortunately many Unix mail programs and libraries recognise and/or use
\n as a line termination (both Gmime and libmutt make this fundamental
implementation error). Sendmail propagated this error. It is also why
qmail makes such a big deal about line endings.
Brian
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail