Summary: | eols get converted | ||
---|---|---|---|
Product: | Claws Mail (GTK 2) | Reporter: | Lars <nospamplease> |
Component: | Plugins/Privacy/PGP | Assignee: | users |
Status: | RESOLVED INVALID | ||
Severity: | normal | CC: | mike |
Priority: | P3 | ||
Version: | other | ||
Hardware: | PC | ||
OS: | Linux |
Description
Lars
2011-09-27 13:52:10 UTC
I can reproduce this, too. Please fix. what is the problem? What is yours? Claws-mail should not cause an attached file to change from sender to receiver. Steps to reproduce: 1) Type a TeX file, e.g.: gedit test.tex 2) cp test.tex text 3) Start claws-mail and compose a new email 4) Attach the files "text" and "test.tex" 5) Send the email encrypted with PGP/MIME to yourself 6) Receive email and save the attached files 7) Check the filesize of the newly saved files: ls -l text test.tex 8) Be surprised that "test.tex" is couple of bytes larger than "text" because the eols got converted This is correct for PGP/MIME'ed msgs. See http://www.ietf.org/rfc/rfc3156.txt The only reference to <cr> i saw under the linked file was concerning signed messages but i am not talking about signed messages. However i do expect it to work with signed messages, too. neither did i find anything about handling files with different name suffixes differently. i don't care what creative interpretation of this RFC you can come up with -- for endusers it only matters that sending an encrypted (TeX-)file should not alter the received file without warning. thunderbird(+enigmail) does manage that. doesn't matter if they do it by better understanding the rfcs or less caring about the rfc, their endresult is better. If your text files should be treated as binary, it's enough to set their mime-type to application/octet-stream. |