[Mimedefang] Re: Problem on attachment name

[Kees Theunissen]

On Sat, 13 Jan 2007, Ing. Andrea Vettori wrote:

> I've searched the rfcs.
>

I didn't. I'll base my conclusions on the information that
you supplied.

> From rfc2183 :
>
> disposition := "Content-Disposition" ":"

Rest of your rfc2183 quote snipped. The definition of the
"Content-Disposition" header is not relevant in this case.
Your problem was an unquoted name value in the "Content-Type"
header.

> and from rfc2045 :
>
> content := "Content-Type" ":" type "/" subtype
>               *(";" parameter)
>               ; Matching of media type and subtype
>               ; is ALWAYS case-insensitive.

[ ... ]

>    parameter := attribute "=" value
>
>    attribute := token
>                 ; Matching of attributes
>                 ; is ALWAYS case-insensitive.
>
>    value := token / quoted-string
>
>    token := 1*<any (US-ASCII) CHAR except SPACE, CTLs,
>                or tspecials>
>
>    tspecials :=  "(" / ")" / "<" / ">" / "@" /
>                  "," / ";" / ":" / "\" / <">
>                  "/" / "[" / "]" / "?" / "="
>                  ; Must be in quoted-string,
>                  ; to use within parameter values
>
>
> So it seems to me that unless the file name contains tspecials,
> it's legal to have the filename as a quoted string on the name
> parameter of Content-Type and unquoted string on filename parameter
> of Content-Disposition.

Your problem was _not_ an unquoted string in the filename parameter
of the Content-Disposition header, but an unquoted string in the name
parameter of the Content-Type header.

Below is the relevant part of your first message.

    --Apple-Mail-25--1005158849
    Content-Transfer-Encoding: base64
    Content-Type: application/zip;
            x-unix-mode=0644;
            name=PULSANTI E FRECCE ACCESE.zip
    Content-Disposition: attachment;
            filename="PULSANTI E FRECCE ACCESE.zip"

According to rfc2045 must the value of the "name" parameter be
a token or a quoted-string. And a token cannot contain SPACE, CTLs
or tspecials.
So the only possible conclusion is that this unquoted string with
spaces is _not_ valid.

> So I think it's a mimedefang/MIME handling bug that when unquoted
> string are used on Content-Disposition filename parameter they are
> truncated...

I don't think it's a bug to reject an invalid message.
And I'm not convinced that the handling of the mime-parts by
MimeDefang is causing the trouble. It can also be the virusscanner
when scanning the whole message.

>
> Who should I contact to solve this bug ?

Did you try to contact the sender of the invalid message?


Regards,

Kees.

-- 
Kees Theunissen
F.O.M.-Institute for Plasma Physics Rijnhuizen, Nieuwegein, Netherlands
E-mail: theuniss at rijnh.nl,  Tel: (+31|0)306096724,  Fax: (+31|0)306031204