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/ Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/ https://mail.python.org/archives/list/mailman-users@python.org/ Member address: arch...@jab.org
