mailsend subject arg must not have a trailing space

Maintainer @thess
Environment: ath79 Archer A7 V5, OpenWrt-21.02.0

Basically, mailsend screws up if the -sub argument ends with a newline. Shouldn't it tolerate that, even if inadvisable?

But I didn't put a newline at the end of the -sub argument, which makes this more mysterious, even if that's not mailsend's fault. If the -sub arg has a trailing space, it somehow becomes a newline by the time the mailsend process appears in /procs/$$/cmdline. (I'm not sure how that character substitution happens. It does not happen when I use mailsend interactively, but it does happen when I call it from inside a script. Anyway, fascinating as that issue may be, that's not what this report is about, really.)
Assuming that the -sub argument to mailsend has a trailing newline (as reported in /procs/$$/cmdline), mailsend misbehaves, creating an incorrectly MIME-formatted mail which my spampd flags as such. Sample invocations, /proc/$$/cmdline files, and resulting messages are in the attached file
subject_arg_difference.txt
.
(This was hard for me to figure out because exactly the same invocation of mailsend -- with all args identical from the user perspective -- would either work and not work, depending on whether they were used interactively at a shell prompt or non-interactively from within a script. I would appreciate any enlightenment on how a space becomes a newline at the end of an argument. The workaround I'm using, of course, is to make very sure that there are no trailing spaces in the -sub arg, but the effort involved in finding the problem was, for me at least, nontrivial.)

Start with the attached subject_arg_difference.txt and reproduce the interactive and scripted mailsend invocations, comparing /proc/$$/cmdline with the resulting messages. Then trace mailsend's argument handling; done means the trailing-newline case no longer creates incorrectly MIME-formatted mail and the reported discrepancy is understood.