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.


 > 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

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.

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


Mailman-Developers mailing list -- mailman-developers@python.org
To unsubscribe send an email to mailman-developers-le...@python.org
Mailman FAQ: https://wiki.list.org/x/AgA3

Security Policy: https://wiki.list.org/x/QIA9

Reply via email to