Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The output from GYB does not conform to RFC2822 #488

Open
chjohans opened this issue Nov 10, 2024 · 1 comment
Open

The output from GYB does not conform to RFC2822 #488

chjohans opened this issue Nov 10, 2024 · 1 comment

Comments

@chjohans
Copy link

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. :)

@loglow
Copy link

loglow commented Dec 24, 2024

@chjohans

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:

gyb --email [email protected] --search "newer_than:7d" --fast-incremental

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).

Thanks so much!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants