james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Norman Maurer (JIRA)" <server-...@james.apache.org>
Subject [jira] Resolved: (JAMES-160) AttachmentFileNameIs can't handle national characters in filename
Date Tue, 12 Oct 2010 12:46:33 GMT

     [ https://issues.apache.org/jira/browse/JAMES-160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Norman Maurer resolved JAMES-160.

    Resolution: Won't Fix
      Assignee: Norman Maurer

encode the filename like descripted here does violate the mime rfc. If you really want to
let javamail act like this you can set the system property:


> AttachmentFileNameIs can't handle national characters in filename
> -----------------------------------------------------------------
>                 Key: JAMES-160
>                 URL: https://issues.apache.org/jira/browse/JAMES-160
>             Project: JAMES Server
>          Issue Type: Bug
>          Components: Matchers/Mailets (bundled)
>    Affects Versions: 2.2.0
>         Environment: James running on Suse Linux 8
> JDK version 1.4.2_02-b03
>            Reporter: Christian Andersson
>            Assignee: Norman Maurer
>            Priority: Minor
> AttachmentFileNameIs is not matching on files with national characters in it.
> I have added this configuration in the james configuration (Thanks to Noel for showing
> <mailet match="AttachmentFileNameIs=*.bat,*.com,*.dll,*.exe,*.lnk,*.pif,*.scr,*.vbe,*.vbs,*.wsh"
>           onMatchException="noMatch"
>           class="Bounce">
>     <notice>550 Rejected - Banned type of attachment.  Please contact
> intended recipient.</notice>
>     <attachment>none</attachment>
>     <passThrough>false</passThrough>
>   </mailet> 
> The problem is that it does not Match on files with national characters in them, the
reson for this is that if there are national characters in the filename, the filename gets
encoded and the matcher therefore gets in trouble since it matches against the encoded filename
and not an unencoded filename.
> Example:
> I sent a file called 'øyenblikksfoto1.exe' with mozilla to myself (using an other mail-account)
> this message came through even though it should have been stopped by the matcher.  Here
is what the e-mail code for this attachement looked like.
> Content-Type: application/octet-stream;
>  name="=?ISO-8859-1?Q?=F8yeblikksfoto1=2Eexe?="
> Content-Transfer-Encoding: base64
> Content-Disposition: attachment;
>  filename="=?ISO-8859-1?Q?=F8yeblikksfoto1=2Eexe?="
> and since the matcher matches for *.exe this file gets through, since there is NO *.exe
in that filename  (mozzilla parsed this filename correctly)
> I then had a friend send me an "exe" file through hotmail (I don't have that myself)
the file was called "nånting.exe"  and here is what came to me in the mime-encapsulating...
> Content-Type: application/octet-stream;
>     name="=?iso-8859-1?B?buVudGluZy5leGU= ?="
> Content-Disposition: attachment; filename="=?iso-8859-1?B?buVudGluZy5leGU= ?="
> Content-Transfer-Encoding: base64
> This file also got through to me, but this time not even mozilla could parse that filename...

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message