Yes, I have had the same problem with Outlook deciding to remove EOL characters. There may be an easier or better solution (and I would be interested to know), but we ended up specifying HTML content. And that works (even though the Outlook HTML renderer is not exactly the best).
| [reply] |
Just a guess: As far as I remember, network line endings should generally be CR+LF. (See, for example, RFC5322.) When using "\n" on Unix, this generates just the LF, not CR+LF (unless MIME::Lite replaces "\n" with CR+LF). So Outlook may actually behave correct according to the letters of the RFC in refusing to accept anything but CR+LF as a line break. Yes, it's stupid, and I would expect nothing else from Outlook.
Try replacing "\n" with "\r\n" in the message body.
Alexander
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
| [reply] |
Thank you, afoken, it was quite long ago, but I am almost sure that I did try both LF and CR+LF (at $work, we very often have to deal with EOL differences between *nix and Windows). The strange thing is that Outlook removes some line endings but not all of them and I wasn't able to find out the underlying rule leading to that. Also, it seems that Outlook does that not only for mails prepared with Perl under *nix boxes, but even for message written on Windows platforms with an Outlook client.
| [reply] |
Since determining that Outlook was the problem, I've tried several things to get it to display correctly, including adding a "\r" and trying different Mime types, to no avail. Oddly, changing the contents of the string that displays directly before the timestamp sometimes causes the "\n" to display.
Further, I've tried different email address with different clients, and from the statistically insignificant number of clients I happen to have installed on this machine, it seems to be exclusively an Outlook issue.
Thank you to everyone who took the time to look at this.
Thanks,
cbeckley
| [reply] |
