attachment names

attachment names

[Vladimir Volovich]

Hi!

i received a message (generated by Microsoft Outlook Express
5.50.4133.2400) with attachment; the attachment had the following
headers:

Content-Type: application/x-zip-compressed;
	name="=?koi8-r?B?5MzRINDFzsnRLnppcA==?="
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="=?koi8-r?B?5MzRINDFzsnRLnppcA==?="

The button which gnus displayed was:

[2. application/x-zip-compressed; =?koi8-r?B?5MzRINDFzsnRLnppcA==?=]...

I wonder if gnus behaved correctly not decoding the encoded-words
(i.e. if outlook incorrectly encoded the filename in the headers)?
Or should the button have read:

[2. application/x-zip-compressed; Для пения.zip]...

Best,
v.

Re: attachment names

[Simon Josefsson]

Vladimir Volovich <vvv@vvv.vsu.ru> writes:

> The button which gnus displayed was:
> 
> [2. application/x-zip-compressed; =?koi8-r?B?5MzRINDFzsnRLnppcA==?=]...
> 
> I wonder if gnus behaved correctly not decoding the encoded-words
> (i.e. if outlook incorrectly encoded the filename in the headers)?

No, gnus is correct, outlook is violating MIME specs.  However, it
doesn't seem to be alone in this behaviour, so perhaps we should try
to support QP encoded parameter values anyway.  (The "proper" solution
would be to make every other client support rfc 2231.)

MIME spec says:

   + An 'encoded-word' MUST NOT be used in parameter of a MIME
     Content-Type or Content-Disposition field, or in any structured
     field body except within a 'comment' or 'phrase'.

Re: attachment names

[Christoph Conrad]

>>>>> "Simon" == Simon Josefsson <sj@extundo.com> writes:

A simple workaround:

;; -cc-
(require 'rfc2047)

(defun rfc2231-parse-string (string)
  "Parse STRING and return a list.
The list will be on the form
 `(name (attribute . value) (attribute . value)...)"

  ;; -cc-
  (setq string (rfc2047-decode-string string))

  (with-temp-buffer
    (let ((ttoken (ietf-drums-token-to-list ietf-drums-text-token))
	  (stoken (ietf-drums-token-to-list ietf-drums-tspecials))
	  (ntoken (ietf-drums-token-to-list "0-9"))


Mit freundlichen Grüßen / Best regards

i. A.
Christoph Conrad

-- 
CLI-GmbH,  Matthiashofstr. 28-30,  D-52064 Aachen
Fon: +49 241 47051-0  Fax: +49 241 47051-89 Web: http://www.cli.de
(defvar my-computer '((OS . "GNU Emacs") (system-type . gnu/linux))
	"Programming environment.")

Re: attachment names

[Simon Josefsson]

[ding: cc of a private response, with a solution to the problem in
this thread]

Christoph Conrad <C.Conrad@cli.de> writes:

>     Simon> No, gnus is correct, outlook is violating MIME specs.
>     Simon> However, it doesn't seem to be alone in this behaviour, so
>     Simon> perhaps we should try to support QP encoded parameter values
>     Simon> anyway. (The "proper" solution would be to make every other
>     Simon> client support rfc 2231.)
>
> I found a simple workaround:

The following won't require modifying gnus, which probably is more
future-safe.

(require 'mail-parse)
(defun my-parse-string (string)
  (rfc2231-parse-string (rfc2047-decode-string string)))
(defalias 'mail-header-parse-content-type 'my-parse-string)
(defalias 'mail-header-parse-content-disposition 'my-parse-string)

Do you all think Gnus should handle this by default, even though it's
wrong?  It would cause problems (only) if someone actually intended
the filename to be a valid QP encoded word.  That isn't very likely
IMHO.

Re: attachment names

[Kai Großjohann]

On 03 Nov 2000, Simon Josefsson wrote:

> Do you all think Gnus should handle this by default, even though
> it's wrong?  It would cause problems (only) if someone actually
> intended the filename to be a valid QP encoded word.  That isn't
> very likely IMHO.

Right.  Maybe we don't even need a user option for turning it off.

Or does it cause us to lose points in GNKSA?  Then the user option
should be to not handle it by default.

kai
-- 
The arms should be held in a natural and unaffected way and never
be conspicuous. -- Revised Technique of Latin American Dancing

Re: attachment names

[Christoph Conrad]

>>>>> "Simon" == Simon Josefsson <sj@extundo.com> writes:

    Simon> The following won't require modifying gnus, which probably is
    Simon> more future-safe.

Good, it works.

But it seems to interact with the extension described in:

gnus.ding
Message-ID: <2nvgu5y4cm.fsf@tiger.jia.vnet>
!* [  31: ShengHuo ZHU        ] Re: Suggestion for saving attachments

Try to externalize an attachement like this, and then redisplay the
message/news. In my gnus the redisplayed message has a garbage looking
attachment.

    Simon> Do you all think Gnus should handle this by default, even
    Simon> though it's wrong? It would cause problems (only) if someone
    Simon> actually intended the filename to be a valid QP encoded word.
    Simon> That isn't very likely IMHO.

Maybe you could make it optional (switchable).

Mit freundlichen Grüßen / Best regards

i. A.
Christoph Conrad

-- 
CLI-GmbH,  Matthiashofstr. 28-30,  D-52064 Aachen
Fon: +49 241 47051-0  Fax: +49 241 47051-89 Web: http://www.cli.de
(defvar my-computer '((OS . "GNU Emacs") (system-type . gnu/linux))
	"Programming environment.")

Re: attachment names

[Christoph Conrad]

>>>>> "Simon" == Simon Josefsson <sj@extundo.com> writes:

    Simon> The following won't require modifying gnus, which probably is
    Simon> more future-safe.

Another possibility would be to:

(defadvice rfc2231-parse-string
  (before rfc2231-parse-string-decode-string act)
  (ad-set-arg 0 (rfc2047-decode-string (ad-get-arg 0))))

Mit freundlichen Grüßen / Best regards

i. A.
Christoph Conrad

-- 
CLI-GmbH,  Matthiashofstr. 28-30,  D-52064 Aachen
Fon: +49 241 47051-0  Fax: +49 241 47051-89 Web: http://www.cli.de
(defvar my-computer '((OS . "GNU Emacs") (system-type . gnu/linux))
	"Programming environment.")

Re: attachment names

[Per Abrahamsen]

Simon Josefsson <sj@extundo.com> writes:

> Do you all think Gnus should handle this by default, even though it's
> wrong?  

I think so.

Re: attachment names

[Per Abrahamsen]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> Or does it cause us to lose points in GNKSA?

GNKSA doesn't care.

Re: attachment names

[Simon Josefsson]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> > Do you all think Gnus should handle this by default, even though it's
> > wrong?  
> 
> I think so.

I made the change to CVS Gnus.