[Esd-l] Re: procmail sanitizer and 8-bit attachments.

[Joe Steele]

On Friday, June 20, 2003 11:50 PM, John D. Hardin wrote:
> On Thu, 19 Jun 2003, Tomas Kuliavas wrote:
>
> > > On Wed, 18 Jun 2003, Tomas Kuliavas wrote:
> > >
> > >> Content-Type: application/octet-stream;
> > >> name="=?iso-8859-4?B?seoudHh0LnNjcg==?="
> > >> Content-Disposition: attachment;
> > >> filename="=?iso-8859-4?B?seoudHh0LnNjcg==?="

Hmm... I'm certainly no expert, but the RFCs make it pretty clear 
that the quoted text should be treated as nothing more than literal 
US-ASCII text.  RFC 2047 covers the use of the 'encoded-word' 
notation used above, but the RFC specifically states that:

   + An 'encoded-word' MUST NOT appear within a 'quoted-string'...

   + An 'encoded-word' MUST NOT be used in parameter of a MIME
     Content-Type or Content-Disposition field....

Both of these requirements have been violated.  Nonetheless, I 
presume this entire issue has arisen because certain lame-brained 
MUAs are parsing the filename as an 'encoded-word'?

> > >> Content-Transfer-Encoding: 7bit
> > >
> > > Encoded filenames are a known weakness in the current version. I don't
> > > know if I will be able to add encoded filename handling soon.
> >
> > How about option to block or strip anything that looks like encoded
> > attachment? It may have high false positives rate, but sometimes it is
> > better to have 10 false positives instead of one virus.
> 
> Add a local-rule:
> 
> :0 B hfi
> * ^Content-(Type|Disposition):.*name="=\?iso-8859-[0-9]+\?B\?

Since respectable MUAs should never use the 'encoded-word' syntax 
within a filename, I'd suggest casting a wider net (because character 
sets don't have to begin with "iso-8859-" and because the method of 
encoding doesn't have to be 'B').  Possibly something like:

* ^Content-(Type|Disposition):.*name=.*=\?.*\?


> | formail -A "X-Content-Security: [${HOST}] NOTIFY" \
>           -A "X-Content-Security: [${HOST}] QUARANTINE" \
>           -A "X-Content-Security: [${HOST}] REPORT: Trapped encoded
> filename" 

Alas, because of the restrictions contained in RFC 2047, 
another RFC was written (RFC 2231) which establishes a different 
method for encoding parameter values (such as filenames) for use 
within MIME headers.  To trap it, you'd probably need something like:

* ^Content-(Type|Disposition):.*name(\*[0-9]+)*\*=.*%

Of course, this again runs the risk of trapping false positives.

--Joe