[Mailman-Developers] Re: [MM3-users] Long lines in mail composed by HyperKitty

2021-04-18 Thread Abhilash Raj


> On Apr 18, 2021, at 7:21 PM, Stephen J. Turnbull 
>  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
> lines[1] is HyperKitty.  Nowadays violating the 80 octet
> limit is common and MUAs mostly handle it, but the 1000 octet limit is
> enforced by many MTAs[2]

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 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.

[1]: 
https://gitlab.com/mailman/hyperkitty/blob/master/hyperkitty/lib/posting.py#L93
[2]: https://github.com/django/django/blob/main/django/core/mail/message.py#L188


-- 
thanks,
Abhilash Raj (maxking)


___
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


[Mailman-Developers] Long lines in mail composed by HyperKitty

2021-04-18 Thread Stephen J. Turnbull
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
lines[1] is HyperKitty.  Nowadays violating the 80 octet
limit is common and MUAs mostly handle it, but the 1000 octet limit is
enforced by many MTAs[2]

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.

Discussion greatly desired.

Steve



Footnotes: 
[1]   RFC 5321: MTAs MAY impose a limit >= 1000 octets including
CRLF.  RFC 5322: MUST be <= 1000 octets including CRLF, SHOULD be
<= 80 octets including CRLF.

[2]  In practice, most (?) MTAs just break the line at 998 octets and
insert CRLF rather than reject the message.  I assume they would break
happily in the middle of a multi-byte character, i.e., any non-ASCII
in a UTF-8 text.

___
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