Re: base64 feature request / enhancement ideas

[Jeffrey Walton]

On Sat, Nov 18, 2023 at 11:39 AM Pádraig Brady <P@draigbrady.com> wrote:
>
> On 18/11/2023 09:07, Sadi Yumuşak wrote:
> > I've recently experienced some difficulties in decoding/saving several
> > inline attachments in an EML (Internet Message Format) file saved from
> > Thunderbird (same for GMail web client) using the command "base64 --decode
> > <input> <output>". I've finally managed to do this after some trial and
> > error, some research, and some additional operations before that command
> > work. So I thought maybe base64 could be improved so that it could work
> > without all this additional work. If such features are beyond the scope of
> > coreutils, which should actually be offered via some other utility using
> > "base64" (and "dos2unix" as well as others), please forgive this novice.
> > 1. Support CRLF line endings as well as LF.
>
> I agree with this.
> The base64 RFC references SMTP RFC which mentions native line end 
> representation,
> but with a default of CRLF.
> So we should probably accept both, and I don't see any ambiguity issues etc.
> with accepting both.

As far as I know, the original RFC that specified the grammar that
used the CRLF end-of-line in mail was RFC 1421. RFC 1421 also stated
lines should be 64 characters. RFC 7468 updated the original RFCs to
decode a line with CR, LF, or CRLF. I don't recall if RFC 7468 changed
the length of the line.

And if you are into the old school Unix hacking, you should recognize
CR\0. It was used in very early mail RFCs.

Jeff