Thymeleaf generated text in TEXT mode replaces CRLF with LF?

[rustykrun]

In a spring project, the Thymeleaf (vers. 3.0.15) template is like this:

Label1: [($(var1))]
Label2: [($(var2))]
Label3: [($(var3))]
Label4: [($(var4))]

Dear Sir/Madam,

The rest of the email message continues from here...

In Outlook running on Windows (which is using CRLF as line separator), most of the times, the lines on top, which contains injected variables, end up being inlined, in different ways:

Label1: [($(var1))]
Label2: [($(var2))] Label3: [($(var3))] Label4: [($(var4))]

or

Label1: [($(var1))]
Label2: [($(var2))] Label3: [($(var3))]
Label4: [($(var4))]

For macos, at least, which is using CR by default, the mail content is displayed correctly. The outlook for web also separate the lines correctly, on Windows (because the browsers do react to LF). According to the Thymeleaf documentation, I don't have to add explicit line breaks characters, because the thymeleaf engine detects the template text structure and automatically include them. The server running the application code is linux based, which is using LF as a line separator. I wrote a small script that iterates through the thymeleaf template files, after they are deployed on the application server and replaces all the line breaks chars with CR/LF, before the application starts. It doesn't have any effect. For some of the top lines, the CR/LF are preserved, but for the rest are still gone - actually, replaced with LF. So I assume that is the tymeleaf code, that decides to replace \r\n with \n in some conditions, which I can't figure them out. I put the logging level on trace for thymeleaf, hopping to get more insights, but the majority of the log entries are about the internal thymeleaf cache activity, but very little about the parsing and template conversion logic.

If I add an extra blank line between the rows it is rendered in the resulted text, but the preferred output is the initial one. What else can I try? Is there a way to tell thymeleaf not to replace \r\n with \n? Or is \n hardcoded?