[Users] Problem sending html with really long lines

[Pierre Fortin]

On Sun, 1 Dec 2024 10:32:59 +0100 Slavko wrote:

Hi Slavko,

>Ahoj,
>
>Dňa Sat, 30 Nov 2024 21:59:37 -0500 Pierre Fortin via Users
><users at lists.claws-mail.org> napísal:
>
>> Is there a line length limit when sending .html files?   
>
>Here is general line length limit in email, original was 78 B, now it is
>1022 B (both + CRLF). AFAIK many servers enforces that, some with higher
>limit, but enforces -- either rejects mail (my server case) or
>modifies email body (can violate RFC and/or break DKIM).
>
>> However, the received file has a newline character inserted every
>> 0x2000 (8192) characters, At non-natural code break points, this
>> causes the browser to fail to display the data.  
>
>IMO 8kB is general safeguard...
>
>> What I don't know is if these newline characters are inserted by CM
>> or by my service provider.  
>
>I don't know who add EOLs, but i hope that it was not CM ;-)

Looks like CM adds them; one member (using ThunderBird) of the team sent
the file back to me and it arrived in working order. 

On closer analysis, TB encoded it:
   Content-Transfer-Encoding: base64
When I first open the received message in CM, the attachment shows as:
   [filename.html text/html (5025596 bytes)]
from base64's bloat.

If I click on the attachment icon, the message area is blank; then
return to the message/rfc822 part, the attachment now shows as:
   [filename.html  text/html (3717564 bytes)] 
which is the non-encoded size.
   
>When you attach some file, you can go to Attachments tab (raw
>translation), click by right mouse button on particular item and choose
>Properties and check encoding. In my case (see attached image) the CM
>chose "7bit" for that (random) HTML file, that will send file in
>unchanged state (as is). You can force it eg. to Base64, which will
>encode content and ensure 78B lines (at price of size increase) and try
>again.

Why should I need to do that?  Checking the original sent message, CM
attached it as:
   Content-Type: text/html
   Content-Transfer-Encoding: quoted-printable
   Content-Disposition: attachment; filename=filename.html
with the file split into 75 character lines ending in "="; unless
character 75 is "=', in which case the line is 74 characters and the
source "=" appears on the next line.  Then, every 8K, 0x0a is inserted.

It would seem that CM could base64 encode the attachment (as TB does)
leaving the content recoverable by the recipient.

>IMO, your life would be simpler, if you will not generate as long
>lines, even without email limits...

Not my choice; this file was generated by the plotly software. I
shouldn't need to write a script to add newlines at "safe" places, or
base64 encode it myself.  IMO, at the point CM tries to add 0x0a, it
should instead switch to base64 encoding the attachment rather than
modify the text.

>regards
>

Thanks for the feedback,
Pierre