On Apr 18, 2021, at 7:21 PM, Stephen J. Turnbull <turnbull.stephen.fw@u.tsukuba.ac.jp> wrote:
Hi,
[I prefer discussion be directed to mailman-developers, so Reply-To is set. But if you're not subscribed to -developers, following up here is OK, and I'll eventually summarize to -developers. Just don't followup to both.]
I just noticed that among the agents that send non-conformant long lines1 is HyperKitty. Nowadays violating the 80 octet limit is common and MUAs mostly handle it, but the 1000 octet limit is enforced by many MTAs2
Is this something new that you’ve noticed?
I think previously, Hyperkitty used to wrap lines at 90 characters when displaying them in UI and then I think the replies would’ve been wrapped at 90 + “ >” (2 chars) per line maximum. I may need to confirm this because we don’t do anything else when sending the message or any recent changes to that part of the code.
But recently, when adding support for rich text rendering, I think I removed that 90 char wrap in the UI, so the original line length is preserved and you might be seeing long lines from lists.mailman3.org or mail.python.org servers which run the git master branches.
I think that HyperKitty should format mail per RFC 3676 format=flowed https://tools.ietf.org/html/rfc3676#section-4. However, I don't use "modern" (aka crappy HTML-oriented) clients, so I don't know whether they handle format=flowed properly.
Support for format=flowed is good in the web client (Fastmail) and Mac client that I’ve been using.
Just to confirm this, but the way to implement that would be to add format=flowed to the generated email’s content-type header and then add a CRLF after LINE_LENGTH octects, right?
We use EmailMessage1 from Django2, which is itself a wrapper over Message class form standard library. I don’t know if the BytesGenerator supports some sort of policy when serializing the body, but if not, I guess we can handle breaking lines with CRLF before we pass it to Django.
-- thanks, Abhilash Raj (maxking)