yEnc

yEnc

[9] 119964 – (yEnc) Support yEnc encoding (including multipart) ( 版) <https://bugzilla.mozilla.org/show_bug.cgi?id=119964>

[10] gecko-dev/nsMimeTypes.h at dfd4efa147e3604707e65b502e142aa8e1dce737 · mozilla/gecko-dev ( 版) <https://github.com/mozilla/gecko-dev/blob/dfd4efa147e3604707e65b502e142aa8e1dce737/netwerk/mime/nsMimeTypes.h>

[11] Re: yencoding -- gnus? slrn? - The Usenet Archive ( 版) <http://www.theusenetarchive.com/usenet-message-re-yencoding-gnus-slrn-22351483.htm>

No, the approach proposed in that message just doesn't make any sense.

It's still using magic text strings.

yEncode as a content transfer encoding is not at all incompatible with

MIME. It's actually quite straight-forward. Take the current yEnc

encoding rules, strip out the needless begin and end markers, remove the

checksum in favor of using Content-MD5, and call it a content transfer

encoding of x-yencode using the standard MIME encoding rules. All done.

As a content transfer encoding, there's no need to worry about multipart

messages, interaction with other MIME parts, or any of that. It just all

falls neatly out of the existing rules for content transfer encodings.

Any MIME part that's encoded using yEncode has in its header section the

line:

Content-Transfer-Encoding: x-yenc

and the body of that part is yEncode-encoded information.