On Fri, Sep 18, 2020 at 7:31 AM Ned Freed
<ned(_dot_)freed(_at_)mrochek(_dot_)com> wrote:
Hi all,
it has become customary to encode text messages in base64. This is
presumably
an attempt to avoid breaking the body hashes of DKIM signatures.
The usual reason it's done is so that you don't have to fix your HTML
generator to produce shorter lines, or lines at all.
I don't believe it is possible to conform arbitrary html to 998+2
transparently due to things like pre. I tried a couple years ago but the
best I could come up with was a kludge to wrap lines with <!--
--> which seemed fairly horrible to me and I gave up.
I'm afraid I don't see the relevance. There's a ton of stuff in HTML that works
fine in a web browser but for various reasons doesn't work if at all in email,
and I suspect avoiding all of that is far more of an inconvenience than not
being able to have really long lines of preformatted text.
If it was just pre,
you could probably do it 90% of the time with a simple implementation but
if it has css, you have to understand that which I think is a dealbreaker.
That's all fine and dandy, but the reality is that encodings are going to get
removed sooner or later, and in certain environments that rightly or wrongly
impose restrictions things like line length, restrictions which will result in
suboptimal behavior.
In any case, my point wasn't that you can't or shouldn'tuse encodings to send
text material with arbitrarily long lines through email. Of course you can, and
there are plenty of cases where there's no useful alternative. But in the
specific case of HTML, the results can be less than ideal, so some
consideration should be given to avoidance. (Of course there's always the "view
this email in a web browser" trick...)
This all happened before my time but AIUI 8BITMIME came before utf8 had won
out so it allowed nulls which must have been pretty traumatic for software
based on null-terminated strings to support but still requires 998+2 which
hampers its utility for html today. It's simple enough to devise a binary
-> 8bit cte but for the trouble to deploy it, you might as well go all the
way to BINARYMIME.
We tried throwing this particular party. Only a few RSVPs, and then nobody
showed up.
Ned
_______________________________________________
ietf-822 mailing list
ietf-822(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-822