Hi Dave, Hi Tobias, Hi all,
I took another look at the multipart sources of the vm-lists which I cannot read in my client. The difference seems to be that on squeak-dev, the order of MIME parts is:
multipart/mixed
- multipart/alternative - - text/plain - - text/html - text/plain (Content-Disposition: inline, the empty stub)
Whereas on vm-dev, the outer MIME parts are ordered the other way around:
multipart/mixed
- text/plain (Content-Disposition: inline, the empty stub) - multipart/alternative
- - text/plain - - text/html
I confirmed by experiment that my mail client (Outlook Web App) only displays the first multipart element, even if it is empty, so the order matters indeed.
I also sent a test message to vm-dev (please forgive me the noise!) with just a single multipart/alternative, and the mailing list automatically wrapped it into a multipart/mixed. So Tobias seems to be wrong and mailman does indeed manipulate the contents of each message.
I think this behavior violates rfc1341https://www.w3.org/Protocols/rfc1341/7_2_Multipart.html:
Mail gateways, relays, and other mail handling agents are commonly known to alter the top-level header of an RFC 822 message. In particular, they frequently add, remove, or reorder header fields. Such alterations are explicitly forbidden for the body part headers embedded in the bodies of messages of type "multipart."
And later:
In general, user agents that compose multipart/alternative entities should place the body parts in increasing order of preference, that is, with the preferred format last. For fancy text, the sending user agent should put the plainest format first and the richest format last. Receiving user agents should pick and display the last format they are capable of displaying.
So according to the RFC, mailman/the list should not add its empty inline field at all (it just adds no value to the reader, right?). But if it needs to stick with that extra field (why?), according to the RFC, the current order is already correct. Also, my client clearly violates this point of the RFC as it displays the first instead of the last mixed element.
Dave, mailadmins, whoever is responsible for this list, do you have any option to reconfigure mailman to have it work just like it works for squeak-dev, or just remove the superfluous mime element at all? I will also try to report this bug to Microsoft, but my gut tells me that I won't be able to convince them to follow the standards ... they never did. :-)
Best,
Christoph
----------------------------------------------------------------------
Message: 1 Date: Wed, 4 May 2022 18:51:12 +0200 From: Tobias Pape Das.Linux@gmx.de To: Open Smalltalk Virtual Machine Development Discussion vm-dev@lists.squeakfoundation.org Subject: Re: [Vm-dev] [list] Cannot receive plain-text messages Message-ID: 4D28BEB3-A6D6-41EE-83FE-0961B758F257@gmx.de Content-Type: text/plain; charset=utf-8
On 4. May 2022, at 18:36, Thiede, Christoph Christoph.Thiede@student.hpi.uni-potsdam.de wrote:
Hi Marcel,
(currently I have switched to the digest subscription option so that I can receive your answers :D)
Thanks for the details!
... and Tobias just told me that mailman does not change that stuff but forwards the content it gets. So the issue is how mail clients or SMTP servers push out that stuff. And we cannot control that.
This is strange ...
Object pinning vs. garbage collection
We are sending messages for commits to VMMaker and Trunk to vm-dev and squeak-dev. Do those look okay on vm -dev for you?
I have not subscribed enough time ago to receive any VMMaker message. I will report back. :-)
What about my messages to vm-dev from April 2022? Were you subscribed then?
For instance in the thread "Object pinning vs. garbage collection", I cannot read any of your messages:
Well, OWA is dumb as heck. It has no idea of multipart mixed, apparently and freely reëncodes emails you sent over it. Avoid it like plague.
-t
<pastedImage.png>
Best, Christoph
Von: Vm-dev vm-dev-bounces@lists.squeakfoundation.org im Auftrag von vm-dev-request@lists.squeakfoundation.org vm-dev-request@lists.squeakfoundation.org Gesendet: Mittwoch, 4. Mai 2022 16:41 Uhr An: vm-dev@lists.squeakfoundation.org Betreff: Vm-dev Digest, Vol 191, Issue 2
Send Vm-dev mailing list submissions to vm-dev@lists.squeakfoundation.org
To subscribe or unsubscribe via the World Wide Web, visit http://lists.squeakfoundation.org/mailman/listinfo/vm-dev or, via email, send a message with subject or body 'help' to vm-dev-request@lists.squeakfoundation.org
You can reach the person managing the list at vm-dev-owner@lists.squeakfoundation.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of Vm-dev digest..."
Today's Topics:
- [list] Cannot receive plain-text messages (Thiede, Christoph)
- Re: [list] Cannot receive plain-text messages (Marcel Taeumel)
- Re: [list] Cannot receive plain-text messages (Marcel Taeumel)
Message: 1 Date: Wed, 4 May 2022 13:58:03 +0000 From: "Thiede, Christoph" Christoph.Thiede@student.hpi.uni-potsdam.de To: "vm-dev@lists.squeakfoundation.org" vm-dev@lists.squeakfoundation.org Subject: [Vm-dev] [list] Cannot receive plain-text messages Message-ID: 3483f711b6594b8bbf9a313a2af667c3@student.hpi.uni-potsdam.de Content-Type: text/plain; charset="iso-8859-1"
Hi all,
while I have subscribed to squeak-dev for a longer time, I only subscribed recently to vm-dev. Unfortunately, I cannot view most messages in my e-mail client - I only see an attachment of the HTML file. It appears as if the plaintext version of the message is missing and the HTML version is classified incorrectly. This does not regard messages from the OSVM bot (GitHub) only but also normal messages sent by Eliot, Marcel, et al. - but at the same time, the messages sent by the same person to squeak-dev look fine on my end.
In other mailing clients (and in Squeak Inbox Talk), everything looks fine, but I do not want to switch away from OWA. In the message headers, I could not find any interesting difference. My subscription settings for both lists are identical. I also noted that the pipermail archives do not look identical, but this is probably unrelated.
Any ideas on what might cause this, and any chance to fix this in the mailing list configuration/servers?
Thanks in advance,
Christoph