In mail send using WebGUI::Mail::Send, sometimes strange exclamation marks appear in the received message. These are followed by a space, and then a newline, then the message continues as normal:
Previously, from 2003 until 2006, he served as Vice President of Researc!
h and Development.
This seems most likely caused by a hard limit of 998 characters on a single line in the SMTP protocol which MIME::Entity and Net::SMTP do not seem to implement themselves. Here's an article describing the relevant portions of RFC 2822.
This is critical because it can destroy HTML formatting, leading to broken, non-working e-mails.
The simplest solution to this would be to use base64 encoding on the message, which makes it trivial to keep under the line length limit.
That has the downside of rendering the messages unreadable directly from the database though, which could be problematic for debugging. Other options include only using base64 for messages that go over the limits, or automatically inserting line endings in the message.
I don't like the idea of inserting line endings, so I think base64 is the way to go. Do you think it would be worth avoiding base64 for messages that don't go over the limits?
The main problem is that the TinyMCE seems to like removing all line-breaks. Even a message I got from the buglist today had a "! \n" string in it.
I would say the right thing to do would be to insert the line-breaks after 900 characters + a space, or if there's no space, the first previous character that happens to be a space. Or even earlier. The RFC says it SHOULD break after 78 chars.
I don't like the idea of base64 encoding the whole thing for performance reasons mostly. The same site sends 1,000+ e-mails on a slow day. Plus, as you mentioned, the added obfuscation.
Perhaps the real "right thing to do" would be to completely re-format the line-breaks based on what type of content it's getting: HTML or Text.
Ugly problem with no pretty solution...
I fixed this by using the core Text::Wrap module and telling it to wrap as soon as possible after 78 characters. This will solve the problem we're seeing.
Fixed in 7.4.21. Closing as resolved.
