kevin--- via Mailman-Users writes:
> Hi, Mark, thanks for replying.
>
> This is what appears when I choose "View -> Message Source" in Evolution:
This appears to be from your "Sent" folder, not the message as
received via the mailing list. I suspect Mark wanted the latter.
> Content-Type: text/plain; charset="UTF-8"
> Content-Transfer-Encoding: quoted-printable
The above fields are what they should be for correct display of the
message.
> User-Agent: Evolution 3.52.3-0ubuntu1
I've never used Evolution, and after seeing the content below, I don't
think I ever will. As a mail composition agent, this is distressingly
ugly.
> For your information, and please publicize:
> =C2=A0
The "=C0=A0" are the representation of the "no-break space" character
(NBSP) encoded in UTF-8 and then further encoded in quoted-printable
(QP) to avoid 8-bit characters. Why Evolution inserts the spurious
NBSP on an otherwise emmpty line here I don't know. It may have
something to do with HTML.
Note that in the "intended message" in your original post, these are
regular spaces (encoded as a single byte, 0x20), not NBSP, as shown
both in the "as delivered" version in that post and in the "raw
message" excerpted above. Something strange is going on here
(although it might just be cut and paste from your mail program or
terminal window).
> on Thursday April 3 and run through June 19 at 6:30 PM Eastern time.=C2=A0
Here's a spurious NBSP at the end of the line.
> A detailed syllabus will be published before the classes begin.=C2=A0 Atten=
> d
This odd sequence includes a NBSP (I think some agents do this to
ensure that a two-space break between sentences doesn't get
"collapsed" to a single space), and a trailing "=" which means "ignore
this newline and join up the line before with the line after. This is
required by the QP encoding, which allows a maximum of 76 ASCII
characters on a line.
> them all, or any that you like, but you must register for the classes.=C2=
> =A0
This is amusing: Evolution breaks up a UTF-8 character into two
individual bytes across a newline. This is technically OK for QP,
which is byte-oriented and knows nothing about non-ASCII encodings,
but it's ugly.
> Note that it doesn't appear this way when I view the message
> normally in Evolution, either as plain text or HTML formatted.
Bottom line: Mailman should "do the right thing" with this message.
Recipients who get the mail from the list should see what you expect
them to see.
What you showed in the original post has the mail being encoded
*twice* with QP. It's possible that there's some weird bug in Mailman
or the Python standard library "email" package causing double
encoding, but I think it's more likely that some other software
between the original composition and Mailman doing the redundant
encoding. This double encoding is not present in the "raw" message.
You also state that your client is set up to send plain text but you
received it as HTML. If it was sent as plain text but received as
HTML, that is not Mailman's doing. Mailman has no option to convert
plain text to HTML (it can do the reverse, however, if you have
software like lynx or w3m installed on the Mailman server).
In the original post you wrote:
> My setup: Linux Ubuntu 24.04 running Evolution 3.52.3 email client.
> Email lists running version 2.2.0.
Are you sure you're running Mailman? There were tentative plans for a
2.2 version but as far as I know there was never a public release,
even as a beta. The current release of Mailman 2 is 2.1.39. If you
are in fact running "2.2" you didn't get it from us. Are you perhaps
running cPanel? cPanel recently announced they were "taking over"
Mailman 2 development, and it is known to have problems. But we have
nothing to do with that, and don't have access to the source. We
don't know what it might be doing. You would have to talk to them.
Or perhaps you got it from Ubuntu, but again you'd have to talk to
them.
> Thanks for any suggestions you have.
The only thing I can think of without more information is that the
message was composed by first saving the draft to a file in QP form,
then pasting that file into a new composition window rather than
"continuing" the original composition. I think a human would notice
this, but perhaps you are using some kind of mailmerge software that
doesn't understand QP and blindly interpolates variable text into the
file without decoding it, then automatically sends it to Mailman.
And of course I can't 100% rule out some kind of bug in Mailman, but
Mailman has been dealing with QP correctly for 3 decades now. I can't
guess why it would suddenly pop up now.
Perhaps Mark will see something in the raw message I didn't.
Steve
--
Mailman-Users mailing list -- mailman-users@python.org
To unsubscribe send an email to mailman-users-le...@python.org
https://mail.python.org/mailman3/lists/mailman-users.python.org/
