Abhilash Raj writes: > Is this something new that you’ve noticed?
I've been noticing long-lines in format=fixed (ie, the default setting) for a while, but hadn't paid attention to the sending clients. For some reason I was rooting around in the headers of this particular message, and saw HyperKitty and that kinda tickled my RFC wonk reflex. :-) > I think previously, Hyperkitty used to wrap lines at 90 characters > when displaying them in UI UI shouldn't have anything to do with the message as formatted for the wire, though. I'm not seeing this in the UI, I'm seeing a message *sent from the HyperKitty UI*, viewed in my usual Emacs-based MUA. > 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, This shouldn't be related to my issue. > > 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. Good! > 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? No, basically the idea is to take a message formatted for fixed-length lines, and allow the receiving client to reflow paragraphs as it wants to. The method is to add "format=flowed" to the generated MIME body's content-type header field, and then append an ASCII space to the end of each line that is part of a flowable paragraph. Each paragraph ends with a fixed line (no trailing space). Preformatted tables and ASCII art are supported by simply not adding the space. Obviously that is not an easy thing to do for a plain text message body source, but should be easy for Markdown source. The rules for handling quoted material are non-trivial and not very smart. Eg, the quoting style where the writer's initials appear before the ">" as in "sjt>" is not supported, and will be very ugly if flowed. See the RFC for that. https://tools.ietf.org/html/rfc3676#section-4 I would expect that email.message supports generating format=flowed message bodies, at least the simple case of a series of flowed paragraphs, but I haven't checked. > We use EmailMessage[1] from Django[2], 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. That's helpful, thanks! Yes, I suspect that we should do our own rendering. Steve _______________________________________________ Mailman-Developers mailing list -- mailman-developers@python.org To unsubscribe send an email to mailman-developers-le...@python.org https://mail.python.org/mailman3/lists/mailman-developers.python.org/ Mailman FAQ: https://wiki.list.org/x/AgA3 Security Policy: https://wiki.list.org/x/QIA9
