Brandon Long <blong(_at_)google(_dot_)com> writes:
I would be remiss if I didn't mention that one of my colleague's here at
Google thinks this is all silly, and we should instead figure out how to
not base64 encode the messages in the first place, but I think that's a
higher barrier than this.
We specified the NNTP protocol as being basically binary-clean (you still
have to do dot-stuffing, and you have to have a newline at the end of the
message, but it's mostly there), and most implementations *mostly* cope,
but clients are another matter entirely. (Ideally, we'd want an even more
binary-clean transport, but the NNTP one is close enough.)
Note that, in the NNTP world, yEnc has some traction as an encoding
format. I tried to convince the author to write it up as a MIME encoding,
with absolutely no luck, but it should be possible to do. I think Ned
Fried took a crack at it?
I did. See:
It's basically a minimal encoding to deal only
with the flaws found in actual NNTP implementations (such as not coping
with nuls and unmatched CR or LF characters) and dot-stuffing, and is
pretty close to not compressing.
Correct. I never pursued it because there didn't seem to be anywhere near
the necessary level of interest.
And it's not hard to see why. The problem with this scheme is that you have
to have support in the clients at both ends, or you end up sending what
amounts to garbage as far as the recipient is concerned.
Of course you could have some way to determine whether or not a given
recipient is capable of receiving such objects. But any scheme that requires
users to maintain this information is pretty clearly a nonstarter, and
how you'd do it automatically without a large chunk of new infrastructure
is unclear to me.
Another concern is that AS/AV software will have to be updated to support
the encoding. Without this support being in place you're going to see messages
blocked because they contain a big blog of stuff the scanner doesn't
understand. I note that this makes any sort of recipient capability
discovery much less valuable.
ietf-smtp mailing list