You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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" [email protected]
(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. :)
The text was updated successfully, but these errors were encountered:
I'd also like my backed up .eml files to have CRLF line endings. Can you help me understand exactly how to setup the substitution you described using sed? Sorry I'm not quite following your example command above, my experience using command line pipes is sadly very limited. My fast backup command currently looks like this:
How would I modify this to make all the backed up files have proper CRLF endings? I'm using macOS if that makes any difference (I know some commands use slightly different flags on mac systems).
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" [email protected]
(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. :)
The text was updated successfully, but these errors were encountered: