Summary

gog gmail get <id> --format raw fails on many messages with:

illegal base64 data at input byte <N>

It prints the envelope lines (id / thread_id / label_ids) and then dies, so the raw
RFC822 output is never emitted. --format full and --format metadata work on the same
message — only raw is affected.

Repro

gog gmail get <id> --format raw       # fails: illegal base64 data at input byte <N>
gog gmail get <id> --format full      # works
gog gmail get <id> --format metadata  # works

Affected class

Not multipart- or attachment-specific, though larger messages hit it more often by chance.
The Gmail API's raw field is padded base64url. Whether it fails depends only on the
RFC822 byte length:

• length divisible by 3 → no = padding → decodes fine
• length not divisible by 3 → 1–2 trailing = padding chars → fails

So roughly two-thirds of messages fail. In every failing case observed, the reported byte
offset <N> is exactly the index of the first = padding character (at the very end of the
base64 string). Example: a message with a 91208-char raw field failed at byte 91207 — the
lone trailing =.

Root cause (v0.34.0)

internal/cmd/gmail_get.go:130 decodes the API raw field with the unpadded URL
encoding:

decoded, err := base64.RawURLEncoding.DecodeString(msg.Raw)

The Gmail API returns raw as padded base64url, but base64.RawURLEncoding is the padding-
free variant and rejects the trailing = as illegal input — hence "illegal base64 data at
input byte " pointing at the padding.

Suggested fix

Use the padded URL encoding:

decoded, err := base64.URLEncoding.DecodeString(msg.Raw)

For robustness against responses that omit padding, normalize first (e.g. strip trailing =
and use RawURLEncoding, or pad to a multiple of 4 and use URLEncoding). A regression test
should cover a raw value whose decoded length is not a multiple of 3.

Environment

gog v0.34.0. Root cause confirmed by reading source at internal/cmd/gmail_get.go:130.