Quote:
|
Originally Posted by dkarp I think you've misread RFC 3501. The RFC does not mandate that every piece of data returned by the server be CRLF-terminated, it just mandates that the server CRLF-terminate every server response, either tagged or untagged. The message body is *part* of a response, and thus the server really shouldn't be tacking on extra CRLFs. |
Fair enough... I've glanced at RFC822, and it doesn't seem to insist that messages end with CRLF...
Quote:
|
Originally Posted by dkarp It seems that fetchmail is not taking the octet count and reading that number of bytes off the wire, but is instead taking the octet count and reading *lines* until it fills its expected buffer. This is completely wrong. Thunderbird gets it right. |
Yup, from my reading of fetchmail's source code, this is exactly what it does (see the function readbody() in
http://mknod.org/svn/fetchmail/trunk/transact.c). I'm using the latest version of fetchmail (6.3.2).
Quote:
|
Originally Posted by dkarp That being said, if fetchmail has this bug, Zimbra needs to work around it. (Which version of fetchmail are you running?) I *think* we can tack on an extra CRLF to all message bodies, but we'll need to make sure that we're not breaking anything else in the process... |
Or rather, I think Zimbra needs to make sure it's not dropping the CRLF field that I think should typically be at the end of every received message body... (how is it even possible to send a message via SMTP without that CRLF?)