If you are forwarding a message inline automatically via a filter, it seem you would want to not change the format even if you normally compose messages as html. So is converting plaintext to html when forwarding via filter also a (new) bug? Also, if you compose in text you might want html messages auto-forwarded via filter go out as html, but I assume the html is converted to text. Anyhow, was hoping detect the missing last CRLF at the protocol file stream level rather than trying to find exactly where the missing CRLF is occurring with the various application scenarios described in this bug. That hasn't worked so I'm now looking that the applications (filtering, forwarding, converting to html, base64 encoding, etc). If I can't find the problem at the application, I may still try to fix at an even lower protocol level by inserting a usually redundant CRLF at the end of each sent message rather than assuming the application always ends the message with CRLF. https://searchfox.org/comm-central/rev/7bf30c9070215a6fcb51fe51fc89bfd5e8c7e6fb/mailnews/base/util/nsMsgProtocol.cpp#1216
Bug 1222046 Comment 45 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
If you are forwarding a message inline automatically via a filter, it seem you would want to not change the format even if you normally compose messages as html. So is converting plaintext to html when forwarding via filter also a (new) bug? Also, if you compose in text you might want html messages auto-forwarded via filter go out as html, but I assume the html is converted to text. Anyhow, was hoping detect the missing last CRLF at the protocol file stream level rather than trying to find exactly where the missing CRLF is occurring with the various application scenarios described in this bug. That hasn't worked so I'm now looking that the applications (filtering, forwarding, converting to html, base64 encoding, etc). If I can't find the problem at the application, I may still try to fix at an even lower protocol level by inserting a usually redundant CRLF at the end of each sent message rather than assuming the application always ends the message with CRLF. https://searchfox.org/comm-central/rev/7bf30c9070215a6fcb51fe51fc89bfd5e8c7e6fb/mailnews/base/util/nsMsgProtocol.cpp#1216 Edit: Found the root cause of the problem and fixing it there (see comment 49).