RFC: Future developments and proofreading

From: Bjarni Runar Einarsson (
Date: Mið 08 Nóv 2000 - 11:01:24 UTC

Hi everyone,

I just wanted to let you know that I'll be releasing revision 1.28 of
the sanitizer as soon as someone familiar with qmail proofreads the
qmail chapter in , the fancy
new HTML manual I wrote for this release. :-) 1.28 solves the problems
discussed here last week, except for the Microsoft TNEF issue, which
is rather complicated. So if you know qmail and want to help get 1.28
out the door sooner, take a look...

At the moment I suspect that native support for TNEF encoding within
Anomy isn't very likely, since it won't fit very well in with the
streaming model used in the sanitizer. So TNEF will have to be
handled by an external tool, more-or-less like other archives (zip,
tar.gz, etc).

Related to this, is the question of adding support for MIME-type
policies, in addition to the current filename policies. This is
especially important for handling attachments which are unnamed (such
as application/ms-tnef). I have the following ideas, but I haven't
decided which I prefer:

1. Create a table defining "default names" for unnamed attachment
   types. E.g. the default for text/html could be "unnamed.html",
   the default for application/ms-tnef would be "winmail.dat".
   This allows people to continue defining their policies based on
   file names.

2. Compare the file_list_N variable with the filename *and* the
   MIME-type. So the TNEF rule might end up looking like this:
     file_list_N = ^(?i)(application/ms-tnef|winmail.dat)$

3. Create a completely new rule type, file_mimelist_N, which is used
   to check MIME-types. If both a file_mimelist_N and file_list_N
   variable were present, then *both* would have to match for the
   policy to be applied.
4. Combine 2. and 3.

(I'm currently leaning towards option 1. since that is the simplest
 solution and would also allow me to distribute a canned
 MIME-type->filename table, instead of placing the entire burdon on
 the person writing the policy.)

Then there's another idea I had, which is related to this - do we want
an option to check the validity of file names and MIME types? By using
a "magic" database (like the file(1) command or File::MMagic module)
the sanitizer could actually check if the filename extension and/or
MIME-type matches the file data itself. If it doesn't, we might want
to assume that someone is trying to sneak stuff by our rules and drop
the attachment, mangle it or rename it to match what the magic
database says it is. Would this make any sense?

I'm already doing some very primitive "magic" checks to figure out
what is inside uuencoded attachments. It would be nice if they were
less primitive. :-)

What do you people think?

Also, I've been discussing things with the AMaViS developers, to see
if they are interested in modularizing their code so Anomy and other
projects could take advantage of their unpacking logic, which is the
most complete out there. AMaViS knows how to unpack almost anything,
so the contents can be scanned for viruses (but that's also about all
it does - it does no sanitization, which is what Anomy is good at).

Finally, I've given up on using Cosource to raise funds for this
project - nothing is happening over there, and I think part of the
problem is that their system is to complicated for what I want to do.
If PayPal didn't have issues with me living in Iceland, I'd just set
up a buisiness account there and accept contributions that way - much
less hassle. Do you have any suggestions for other systems that would
help me to accept online cash donations / payments for support?

Bjarni R. Einarsson                           PGP: 02764305, B7A3AB89              -><-   

Netverjar gegn ruslpósti:

-- This mailing list's home page is: There you can find subscription instructions and possibly an archive. is a free Icelandic mailing list service.

hosted by