Created attachment 1984 [details] Original file (0.html) Good day! 1. Download attached file '0.html' to './0.html' 2. Check: $ du -b 0.html 216627 0.html $ sha1sum 0.html 3dd31f2f5dff65a7c400093a690ade288344ebb6 0.html 3. Open Claws Mail. 4. Compose a message for an e-mail address you could read. 5. Attach './0.html' to the message. 6. Send the message. 7. Open the sent message (in "Sent" mailbox). 8. You'll see attachment and its size: [0.html text/html (237696 bytes)] Why? 9. Save the attachment to './1.html'. 10. You'll see: $ du -b 1.html 216638 1.html $ sha1sum 1.html b26686a6aaa0708d49a2a3a8cbaac29a74d96787 1.html 11. Receive message on email from p.4. 12. You'll see attachment and its size: [0.html text/html (237696 bytes)] Why? 13. Save the attachment to './2.html'. 14. You'll see: $ du -b 2.html 216638 2.html $ sha1sum 2.html b26686a6aaa0708d49a2a3a8cbaac29a74d96787 2.html Why? Are they bugs or features? Thanks!
you say "breaks an attachment", how is it broken?
Created attachment 1985 [details] Received file (1.html == 2.html)
Contents of the attached file is different in the received email.
nothing is broken, it's just the long lines which are wrapped.
Sorry. Which lines? I **attached** a file not insert. How a attachment could be changed at all?
(In reply to comment #5) > Sorry. Which lines? I **attached** a file not insert. How a attachment could > be changed at all? There were 2 really long lines relating to javscript. Attachments are encoded. They are also wrapped so they do not exceed the maximum allowed line length (998 bytes) This is a standard specified in RFC 2822. See https://tools.ietf.org/html/rfc2822 SMTP servers which follow this standard will reject a message which has a line exceeding 998 bytes. There are some servers which do not enforce this standard.
Ok, thank you for explanation! But file is not not changed if I sent it through Roundcube (both email addresses and server is the same). So, client could prevent this issue?
any potential issue is avoided by following RFC 2822
Sorry, don't understand. Send by Claws Mail => no errors, attachment changed Send by Roundcube => no errors, attachment ISN'T changed Servers (sender's, receiver's) are the same in both cases.
Created attachment 1986 [details] Picture 1 Quoted printable attach: look, it already meet RFC2822 - all lines wrapped (see symbol "=" at the string's end). I guess before quted-printable encoding you break html's line on 998 symbol chunks, but it NOT needed. We had three attach types in Claws-mail: base64, quoted-printable, 8bit. First two types no need additional manipulations like insert \n after 998 symbols - they product RFC2822-compatible result. Other hand with 8bit encoding. I think it NEED long lines wrapping. But I think more safe insert \n after last " " (space) in 998 symbol chunks.
Created attachment 1987 [details] Incorrect \n
> Other hand with 8bit encoding. I think it NEED long lines wrapping. But I > think more safe insert \n after last " " (space) in 998 symbol chunks. I think it's anyway very bad for user's data and that variant must be never selected or html.
Paul, messages are damaged. We have an ability to avoid this without RFC violation (as Viktor said). Reopen. Reconsider, please! Thanks.
(In reply to comment #13) > Paul, > > messages are damaged. We have an ability to avoid this without RFC violation > (as Viktor said). Well, 'damaged' is a strong word. There is no damage, as you confirmed yourself, but the longest lines (over 8192 chars) are wrapped. Try this, save the attachment using drag'n'drop. Is it the same or wrapped? I've been investigating this more this morning, and the attachment remains an exact copy until it is saved. (My previous assumption about the 998 character limit was wrong.)
(In reply to comment #14) > Try this, save the attachment using drag'n'drop. Is it the same or wrapped? Maybe I should explain what I mean... The attachments are shown as icons to the right of the message text area. Drag'n'drop the html attachment's icon to a directory in your file system.
Paul, new message, "attach", save message, open message, download attachment via drag & drop => file wrapped (changed). And size of the attachment in the message's view is also incorrect: [0.html text/html (237696 bytes)]. Although original file size is 216627 bytes, wrapped (downloaded) file size is 216638 bytes.
(In reply to comment #16) > Paul, > > new message, "attach", save message, open message, download attachment via > drag & drop => file wrapped (changed). I assume by 'download' you mean 'save'? > And size of the attachment in the message's view is also incorrect: > [0.html text/html (237696 bytes)]. That's the encoded size, not the original size.
Yes. I just dragged and dropped.
Paul, any news on this?
(In reply to Paul from comment #6) Hi, 2 years to remove unneeded line break soon. It's unnecessary to wrap lines if you're going to encode the file. Encoding a file will make it RFC-compliant attachment anyway.
Hi. Bug still here
(In reply to Paul from comment #14) > Well, 'damaged' is a strong word. There is no damage, No, it's a damage. File to attach (binary, PNG, plaintext or HTML) must not be changed, but Claws change it.
It's not just any file, to be fair. Test these, "binary, PNG, plaintext or HTML", to see.