The output from GYB does not conform to RFC2822

I've been using GYB for a few years now. I have automated a few backups for a few different Gmail mail accounts with GYB on a Linux box, and I run it daily by cron (with slightly different options) to make sure everything is backed up. The output from GYB is piped into an email message.

I just noticed that I had stopped receiving those email messages, and coincidentally they stopped at the same time I upgraded my Linux box with the latest Ubuntu release. It turned out that the email system on Ubunto now enforces RFC 2822 more stringent than before.

RFC 2822 (Internet Message Format) specifies among other things that bare CR's or bare LF's are invalid as line separators. Excerpt from RFC 2822: CR and LF MUST only occur together as CRLF; they MUST NOT appear independently in the body.

Most email systems (that I know of) have just ignored this for years, but now I know that at least on Ubuntu 24.04 this is strictly enforced.

My solution to get this working again was to just add a simple sed statement to the piped output from GYB to substitute every LF to a CRLF:
gyb | sed 's/\r/\r\n/' | mail -s"Output from GYB" me@myself.com
(I do some other formatting of the output as well to avoid sending all the individual message IDs, but that is not relevant to this.)

Now I understand why GYB outputs LF's as it does, and it makes it kind of optimized for viewing in a terminal window. But less so for piping to an email program, at least if your email system strictly enforces RFC 2822.

My suggestion is that you add a flag (-crlf ?) is added to GYB to specify that CRLF should always be used instead of just LF's when that flag is used.

Some might even prefer a long scrolling output from GYB even when viewing the output in a terminal window, instead of a line that mostly overwrites itself. :)

Start at GYB's command-line option parsing and the output path used when backup output is piped to mail. Check how line endings are currently emitted and how terminal output is preserved. Done means a documented option produces RFC 2822-compatible CRLF output without changing the default behavior; verify the command-line behavior with a piped output test.

Written by the indexing model from the issue text.