Gnus development mailing list
 help / color / mirror / Atom feed
From: Dmitri Paduchikh <dpaduch@k66.ru>
To: ding@gnus.org
Subject: Re: application/octet-stream sent as 7bit
Date: Thu, 03 Sep 2009 21:59:08 +0600	[thread overview]
Message-ID: <87ws4gnho3.fsf@paduch.telenet.ru> (raw)
In-Reply-To: <b4mzl9cuv23.fsf@jpl.org> (Katsumi Yamaoka's message of "Thu, 03 Sep 2009 20:28:04 +0900")

[-- Attachment #1: Type: text/plain, Size: 1606 bytes --]

Katsumi Yamaoka:

>>>>>> Dmitri Paduchikh wrote:
>> In some cases Gnus sends application/octet-stream attachments in
>> unencoded form:

>> ,----
>>| --=-=-=
>>| Content-Type: application/octet-stream
>>| Content-Disposition: attachment; filename=test.sh
>>|
>>| #!/bin/sh
>>| echo test
>> `----

>> I am concerned that contents can change when transferring a message.
>> Think of EOL conversions, ">From " stuff, etc. Such changes can corrupt
>> shell script, for example.

>> In general, RFC 2046 says that application/octet-stream denotes
>> arbitrary binary data. For arbitrary binary data I would expect that it
>> is transferred exactly as is, even if it looks like a 7-bit text.

> Agreed.  Aren't there any other application/* types that should
> not be forced to be encoded by 7bit?  Otherwise, is it better not
> to force the 7bit encoding to all application/* types?

Hmm... It is unclear to me whether other application/* (or audio/*,
image/*, video/*) require protection from this behavior. Although binary
data most likely isn't 7-bit, it may be 7-bit in principle. IMO, in such
case it would be preferable to provide safe default behavior and means
to change it if user wants to. 7bit enforcement breaks both of these
principles (safe default and user control) thus I would rather remove it
completely as in the patch below. Are there any situations when it is
desirable to enforce 7bit?

> Here are two patches; one is for excluding application/octet-stream,
> the other is for excluding application/*.

Thank you. The following patch is a variation of your patches.

-- 
Dmitri Paduchikh


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 717 bytes --]

diff --git a/lisp/mm-encode.el b/lisp/mm-encode.el
index 39b83ff..963936d 100644
--- a/lisp/mm-encode.el
+++ b/lisp/mm-encode.el
@@ -145,13 +145,7 @@ The encoding used is returned."
 	 (encoding
 	  (or (and (listp type)
 		   (cadr (assq 'encoding type)))
-	      (mm-content-transfer-encoding mime-type)))
-	 (bits (mm-body-7-or-8)))
-    ;; We force buffers that are 7bit to be unencoded, no matter
-    ;; what the preferred encoding is.
-    ;; Only if the buffers don't contain lone lines.
-    (when (and (eq bits '7bit) (not (mm-long-lines-p 76)))
-      (setq encoding bits))
+	      (mm-content-transfer-encoding mime-type))))
     (mm-encode-content-transfer-encoding encoding mime-type)
     encoding))
 

  reply	other threads:[~2009-09-03 15:59 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-30 13:42 Dmitri Paduchikh
2009-09-03 11:28 ` Katsumi Yamaoka
2009-09-03 15:59   ` Dmitri Paduchikh [this message]
2009-09-04  0:31     ` Katsumi Yamaoka
2009-09-04 13:51       ` Dmitri Paduchikh
2009-09-07  8:37         ` Katsumi Yamaoka

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87ws4gnho3.fsf@paduch.telenet.ru \
    --to=dpaduch@k66.ru \
    --cc=ding@gnus.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).