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
