Your message dated Wed, 12 Dec 2012 09:32:36 +0100 (CET) with message-id <[email protected]> and subject line Re: bugs.debian.org: converts text/plain attachmants to Windows linebreaks has caused the Debian Bug report #695632, regarding alpine: mangles line breaks in plaintext attachments to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 695632: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=695632 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: alpine Version: 2.02+dfsg-2 Severity: important Alpine changes thje linebreaks of attached plaintext files to CRLF before base64-encoding and sending them. This is particularly awesome as it seems to be a misfeature rather than an arbitrary bug because it actually fixes this back when asving a plaintext attachment ... or it does something rather stupid to access plaintext files on disk, who knows. Either way, data gets corrupted. Steps to reproduce: 1. Create some plaintext file - in my case, a diff - with UNIX (LF) line endings. We call this before.diff . 2. Send mail to yoursef with alpine and attach before.diff 3. Open mail in alpine after receiving it, hit V and save the attachment as after.diff. 4. Compare the two files and find that they are identical. 5. Now open the raw message and copy the base64-encoded block of the attached file to wire.diff.b64 . 6. base64 -d wire.diff.b64 >wire.diff 7. Compare the three files and find that wire.diff has CRLF line endings - whoot? This leads to incompatibility with other mailers and even to data corruption. What happens if an attached file *is* supposed to have CRLF line endings? Will they be converted before saving the file? My best guess is this: - alpine reads plaintext files line by line when attaching (which is a bug) - alpine defaults to CRLF line endings when handling text data (which is a bug) - alpine writes plaintext attachments line by line with system line endings (which is a bug) In most cases, this will not even be noticed. But especially for sending diffs it can be fatal. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.6-trunk-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/mksh Versions of packages alpine depends on: ii libc6 2.13-37 ii libgssapi-krb5-2 1.10.1+dfsg-3 ii libkrb5-3 1.10.1+dfsg-3 ii libldap-2.4-2 2.4.31-1 ii libpam0g 1.1.3-7.1 ii libssl1.0.0 1.0.1c-4 ii libtinfo5 5.9-10 ii mlock 8:2007f~dfsg-2 Versions of packages alpine recommends: ii alpine-doc 2.02+dfsg-2 Versions of packages alpine suggests: ii aspell 0.60.7~20110707-1 ii postfix [mail-transport-agent] 2.9.3-2.1 -- no debconf information
--- End Message ---
--- Begin Message --------BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, discussion in #695632 has led to the following conclusion: RFC 2046 [1] states that any line break in text/* MIME parts must be CRLF regardless of format. Thus, alpine's way of doing things - converting line breaks to CRLF - is correct and the BTS' MIME interpretation is wrong. The BTS, when decoding text/* MIME parts, has to convert any CRLF to LF ones (as in, strip exactly one CR occurence preceding any LF). This behaviour is also correct for text that had reall CRLF line breaks in its original form as those will be CRCRLF after MIME encoding. We, mirabilos and I, thereby conclude that the BTS corrupts data by not following the RFC for MIME transport. I also chose to close #695632 with this message. Cheers, Nik [1] https://tools.ietf.org/html/rfc2046#section-4.1.1 - - -- * mirabilos is handling my post-1990 smartphone * <mirabilos> Aaah, it vibrates! Wherefor art thou, daemonic device?? PGP fingerprint: 2086 9A4B E67D 1DCD FFF6 F6C1 59FC 8E1D 6F2A 8001 y -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iQFOBAEBCAA4BQJQyEEPMRpodHRwczovL3d3dy5kb21pbmlrLWdlb3JnZS5kZS9n cGctcG9saWN5LnR4dC5hc2MACgkQWfyOHW8qgAG6rwf9FuzC8jF1HOQL3P316XLT erT1zbo/2FSzer7N9MDTAlMLbfz+pNK4/lyt2kPu23O0J/lbVcB1SH/h2yaBZMJm 6sm9vtnpz9Qsa5lFDKJg3zbnYgZYKqMYAmasi3ryxh+wecJJxcVpYkbacpgjSaqy HMGLNaSqFoJ/S7IH9g4yTUL03CWTXHWSWyyVkdNolzlbqcN7PgQZWJE5m2vFMy9a cvZJCM7BqRbvZjfoYGi5A1L0JFwrB+1soSl71pm0HELzfIbVtXGQKhOOBZqrmTsY geILTz88Zn9eJfBPxKiuLRwmYk/N3VaoLZ3NlLsnR/twnqL8IoQpd3LI+F+k0x7l rg== =z+Lg -----END PGP SIGNATURE-----
--- End Message ---
