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: [EMAIL PROTECTED], Tel: (+31|0)306096724, Fax: (+31|0)306031204 _______________________________________________ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang