off-topic a bit, on webpage and email content (Was: Re: Openssl Release Announcement for 3.5.2)

44 views
Skip to first unread message

Steffen Nurpmeso

unread,
Aug 5, 2025, 6:01:30 PMAug 5
to openss...@openssl.org
Hello.

I am sorry as this is about form, not actual programming code.
If you are not interested in this, you may very well just skip
this message entirely.

OpenSSL Announce wrote in
<1581856e-49b5-31bf...@mailsenderam1.com>:

|Openssl Release Announcement for 3.5.2

I do not know how this is generated, but it is really very, very
sad to look at the source code of either part, text or html.
And almost as sad to look at either part, in a non-graphical,
stylesheet interpreting "thing".
If you use donations aka actually pay money for this, you know,
i thought maybe someone is interested in improving.

While being so frustrated on how email is mistreated by, let's say
it, DigitalOcean is the IP behind it, says Whois, i came over to
the openssl-library website, and it seems it is in an only
partially maintained mode! Look for example at [1], it stops in
May, the 3.5* series is not even mentioned!
There is more incomplete data on small pretty pages with few
content. (Imho. But maybe it is because of this that noone has
yet recognized that the entire 3.5 series is missing?)

[1] https://openssl-library.org/news/newslog/index.html

Back to the email. It is shocking how much can be done in a bad
way for almost no content (except links).

Openssl Release Announcement for 3.5.2
=C2=A0=E2=80=8C=C2=A0=E2=80=8C=
=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0=
=E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=
=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0=
=E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=
=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C
=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0=
=E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=
=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0=
=E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=
=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0=
=E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C
=C2=A0=E2=80=8C=C2=A0=E2=80=8C=
[repeated two more times]
=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0=
=E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=
=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0=
=E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=
=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C=C2=A0=E2=80=8C
[https://api.mailsenderam1.com/open/image.png?key=3D60ce153229e852f64d28dd3=
74aeccb179071c0ec47a3a83859b45232b8c9c38bae1c16ac24b0b64c48470a16344a6c00_7=
673bfe89656a8acc74b96052c6de320]

So this entire block, except for the link, is totally useless in
plain text. It seems to misunderstand the concept of plain text
as such! (Note this is not format=flowed text, it really is only
plain text.)
And if, it can all be base64 and would save bandwith. (It could
also be 8-bit, but i agree on a transfer encoding.)

Plain text looks a bit speckled otherwise, but is fine beside
that. It gets rare in the business world, HTML-only it seems to
become.

...
|The OpenSSL Project team announces the release of new versions of our
|open-source toolkit for SSL/TLS.
|
|Release changes:
|
| * The FIPS provider now performs a PCT on key import for DH, RSA, \
| EC and ECX. 

Thanks again for providing actual information!

|For details of the changes, refer to the release notes for version 3.5
|[https://api.mailsenderam1.com/c/53e0e15043302e060d1c1e44e7085b86_630c5c\
|2b41fa43182bf45cfdb48da095?sid=c31f356bc20ba5ebf94f3c7b8cca2764_b0f0cadc\
|50c78536e3205ae110612474&aid=Xp2h].
|[https://api.mailsenderam1.com/c/6961f476321567125fd564a7991cdb9a_fb018f\
|28f3a63dd55746f08801f9530d?sid=c31f356bc20ba5ebf94f3c7b8cca2764_b0f0cadc\
|50c78536e3205ae110612474&aid=Xp2h]

I always wonder why there cannot simply be links to OpenSSL,
i have no business with mailsenderam1 aka DigitalOcean, ... and
surely never will i would say today.

...etc etc: thanks for such infos..

But let us come to the HTML part. This is a non-graphical view,
and i only point out several things. I can only repeat words on
the actual source code behind .. it is terrifying.
It is not only these [note: dependent on your email client you
will not see the HTML entities as HTML source code aka entities,
but expanded to their content: it is only about NBSP entities in
between the same U+200C ZERO WIDTH NON-JOINER as above]

&nbsp;=E2=80=8C&nbsp;=E2=80=8C&nbsp;=E2=80=8C&nbsp=
;=E2=80=8C&nbsp;=E2=80=8C&nbsp;=E2=80=8C&nbsp;=E2=80=8C&nbsp;=E2=80=8C&nbsp=
;=E2=80=8C&nbsp;=E2=80=8C&nbsp;=E2=80=8C&nbsp;=E2=80=8C&nbsp;=E2=80=8C&nbsp=
;=E2=80=8C&nbsp;=E2=80=8C&nbsp;=E2=80=8C&nbsp;=E2=80=8C&nbsp;=E2=80=8C&nbsp=
;=E2=80=8C&nbsp;=E2=80=8C&nbsp;=E2=80=8C&nbsp;=E2=80=8C&nbsp;=E2=80=8C&nbsp=
;=E2=80=8C&nbsp;=E2=80=8C

which possibly would better be encoded as base64, but even better
they would be left off, given the sheer number of CSS stylesheet
information preceding the content. (I wonder why, it seems
stylesheet info is then repeated inline over and over again.) I am
not looking that exactly, i only want to point out to the link

...
|[11]View this email in your browser[/11]
...
| [11] https://api.mailsenderam1.com/templatePreview?key=60ce153229e852f64\
| d28dd374aeccb179071c0ec47a3a83859b45232b8c9c38bae1c16ac24b0b64c48470a163\
| 44a6c00_7673bfe89656a8acc74b96052c6de320&html=true

And if you open that link in a browser, and look at the source
code (and do scroll back over that injected script with AJAX and
polling that is not there in the email), you will see how the
content-transfer-encoding unfolded line looks. Yes, the entire
real content is written as a single quoted-printable escaped line.
I have seen such consciously only once, and kept it in my test
email series (for the MUA i maintain), and that was a Yahoo
webmail in 2013, YahooMailWebService/0.8.131.499.

As a programmer you must hate it, as i think every "consumer" will
unfold this single line into a, well, single line, and that,
i would presume, given almost 14K of bytes -- four pages here! --
means reallocating a single buffer over, and over, and over again,
before the entire line can then be handled further.
(Well, maybe it is not that bad, but i would presume the HTML is
prepared in its entirety before being handled, or does any mail
processing system handle content-transfer-encoding and HTML
processing in chunks in a combined fashion, as they fly by?
I would be surprised, having not seen this yet; but i also do not
look at the source code of the graphical monsters, only servers
and "little" text mode mail user agents.)

So that. Thanks again. Shall you prefer a holistic (and
professional, imho) view of OpenSSL the above may give some
thoughts on improvements in the email and web presence area.
Maybe it is harder for the email part.

--End of <1581856e-49b5-31bf...@mailsenderam1.com>

--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
|
|During summer's humble, here's David Leonard's grumble
|
|The black bear, The black bear,
|blithely holds his own holds himself at leisure
|beating it, up and down tossing over his ups and downs with pleasure
|
|Farewell, dear collar bear

Michael Richardson

unread,
Aug 6, 2025, 2:25:26 PMAug 6
to openss...@openssl.org
I share Steffen's frustation with text/plain parts that aren't really that.

Reply all
Reply to author
Forward
0 new messages