Parsing Content-Type with repeated attributes

Parsing Content-Type with repeated attributes

[David Engster]

I just got a mail with the following Content-Type:

Content-Type: application/x-pkcs7-mime;smime-type=signed-data;name=smime.p7m; smime-type=signed-data; name="smime.p7m"

This belongs to a base64 encoded mail with S/MIME signing. Now, this
Content-Type was obviously produced by some strange mail software
(*cough* X-MimeOLE: Produced By Microsoft Exchange V6.5 *cough*), but
when you run that Content-Type through `rfc2231-parse-qp-string', it
produces

("content-type:application/x-pkcs7-mime"
 (name . "smime.p7msmime.p7m")
 (smime-type . "signed-datasigned-data"))

I first thought this was a bug, but it seems the above rfc2231 function
concats those strings very deliberately... Gnus also actually tries to
verify the mail, but with the old mm-view-pkcs7-verify and I'm using EPG
with gpgsm.

-David

Re: Parsing Content-Type with repeated attributes

[Lars Magne Ingebrigtsen]

David Engster <deng@randomsample.de> writes:

> ("content-type:application/x-pkcs7-mime"
>  (name . "smime.p7msmime.p7m")
>  (smime-type . "signed-datasigned-data"))
>
> I first thought this was a bug, but it seems the above rfc2231 function
> concats those strings very deliberately...

I dimly seem to remember that being specified by the RFC.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Parsing Content-Type with repeated attributes

[David Engster]

Lars Magne Ingebrigtsen writes:
> David Engster <deng@randomsample.de> writes:
>
>> ("content-type:application/x-pkcs7-mime"
>>  (name . "smime.p7msmime.p7m")
>>  (smime-type . "signed-datasigned-data"))
>>
>> I first thought this was a bug, but it seems the above rfc2231 function
>> concats those strings very deliberately...
>
> I dimly seem to remember that being specified by the RFC.

OK, I've read (well, rather skimmed) the RFC, and it defines a
continuation of MIME parameters through the asterisk, followed by a
number:

URL*0="ftp://";
URL*1="cs.utk.edu/pub/moore/bulk-mailer/bulk-mailer.tar"

Otherwise, I don't see that you should concatenate parameter
values. Actually, I couldn't find any specification of what should be
done when parameters are defined several times.

-David

Re: Parsing Content-Type with repeated attributes

[Lars Magne Ingebrigtsen]

David Engster <deng@randomsample.de> writes:

> OK, I've read (well, rather skimmed) the RFC, and it defines a
> continuation of MIME parameters through the asterisk, followed by a
> number:
>
> URL*0="ftp://";
> URL*1="cs.utk.edu/pub/moore/bulk-mailer/bulk-mailer.tar"
>
> Otherwise, I don't see that you should concatenate parameter
> values. Actually, I couldn't find any specification of what should be
> done when parameters are defined several times.

It seems wrong to concatenate them, anyway.  I've now made the code
ignore any repetitions.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen