Long workflow invocation commands break notification emails.

Bug report

If a nextflow pipeline is launched with a very long command, and it's configured to send the automatic "workflow completed" email, the email will be garbled.

This email will appear blank in a mail client, but viewing the email source shows that the content of the multipart sections (but not the syntax defining the sections themselves) is garbled. A distinctive thing I've found is that the affected multipart sections always have an encoding of "quoted-printable", while normal sections don't.

Specifically, once the command is long enough, the HTML section of the email source will be replaced with garbled/truncated HTML, like this:

------=_Part_0_1532989443.1695913517594
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
-width: 800px; margin: 0 auto;">
r: #ededed; padding: 15px; border-radius: 4px; margin-bottom:30px;">nextflo=

(In another case, it was the entire "Licensed under the Apache License..." comment and nothing else in that section.)

If the command is even longer, the plain text version of the email (in a different multipart section) is messed up similarly.

Expected behavior and actual behavior

Expected: I expected the email to contain valid HTML and plain text in the correct multipart sections, even for long workflow invocation commands.

Actual: If the invocation command is longer (in my tests) 850 characters the HTML section is garbled, and if it's longer than 910 characters, the plain text section is garbled as well.

Steps to reproduce the problem

minimal.nf:

nextflow.enable.dsl = 2

process foo {
   exec:
   println "hello world!"
}

workflow {
   foo()
}

Invocation:

nextflow run minimal.nf --param 'Here is a lot of long text to make this too long so this glitches some more text even more text even more text even more text even more text even more text even more text even more text even more text even more text even more text even more text even more text even more text even more text even more text even more text even more text even more text even more text even more text even more text even more text even more text even more text even more text even more text even more text even more text even more text even more text even more text even more text even more text even more text even more text even more text even more text even more text even more text even more text even more text even more text even more text even more text even more text even more text even more text even more text' -N ckumar@neb.com

Program output

The pipeline ran fine, but here's the relevant sections of a failing email:

The email source (with the screenfuls of e.g. "Received" and "X-something-something" headers cleaned up): email.txt

Note the HTML section is not valid HTML.

The .nextflow.log, but I don't see anything abnormal there: nextflow.log

Environment

Nextflow version: 23.04.3
Java version: openjdk 20-internal 2023-03-21
Operating system: Rocky Linux release 8.6 and Ubuntu 18.04.6 LTS (I reproduced this on two different systems)
Bash version: GNU bash, version 4.4.20(1)-release

Additional context

I had this happen with both Nullmailer and Postfix, but the garbled output was different between the two. Nullmailer did the 2 lines of broken HTML in the example above, Postfix did the "Licensed under the Apache License..." comment and nothing else.

nextflow-io / nextflow