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 http://mailtools.anomy.net/sanitizer.html , 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,
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
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 email@example.com -><- http://bre.klaki.net/
Netverjar gegn ruslpósti: http://www.netverjar.is/baratta/ruslpostur/
-- This mailing list's home page is: http://mailtools.anomy.net/archives/anomy-list/ There you can find subscription instructions and possibly an archive. Molar.is is a free Icelandic mailing list service.