Contribute

Do you want to contribute to ze-filter developpement ??? Here are some (not exhaustive) ideas.

ze-filter is distributed free of charge. You don't need to pay to get it. But some people sometimes ask me if it's possible to donate. If you want to donate, I have a list of books which I'll surely be reading in the next future, and will be useful to my research activities. I've created a wishlist at Amazon :

http://www.amazon.fr/gp/registry/wishlist/NC5UTYOAAH5T?sort=priority.

Although you aren't obliged to donate, this is a way to help ze-filter developement.

I'm not doing any advertisement to Amazon. This link is only a place where I maintain a wishlist. If you want to send me one of these books, feel free to get them where it's better for you. I consider this an easy place to organize a wish list - not more than this.

Xavier and Josep from Catalunya (Spain), usuaris.org and geisic.com, donated six books from the wish list. It's a very nice donation as they took the time to choose interesting books between all listed there. I warmly thank them.

ze-filter documentation is a big problems. You can help in many ways :

• Organising documentation
• Writing parts of it
• Spelling corrections
• …

Bug reports are always welcome, if you eventually find some…

Suggestions are welcome !!!

Suggestions and Features request shall be directed to the discussion list in order to hear the opinion of other users, whenever appropriate.

DON'T email the author to ask new features. He will eventually answer you, but he prefers a discussion on the list.

If you ask any feature, it may or not be accepted to be integrated to the filter. Sometimes this generates long useless discussions or even flame wars.

Here are some possible reasons the author will reject asked features :

• If you're asking for a feature which is useful only to you, or only to a very few particular kind of users, the probability that it will be accepted is very low.

• If you're asking for a feature for something which can be better done by the MTA or if the appropriate place to do it is at the MTA, it's better to ask the MTA developpement team to integrate it into their software.

• If you're asking for a feature which is already implemented by another filter, unless there is a good reason, it may be better to use the other filter. A good example is DKIM - the author idea about is to integrate dkim-milter results into ze-filter, instead of reinventing the wheel and doing again what's already very well done by dkim-milter.

• The effectiveness of the asked feature shall be high enough : low error rates, reliability, simplicity (programming, principle, deployment,…), low impact on the filter reliability, performance, latency, …

• The asked feature shall not hurt, in some way, original design decisions or goals of the filter. Most existing users like and use ze-filter as they adhere to its conception. After all, the author will privilegiate satisfying existing users than attracting new ones.

• New features shall not be incompatible with different OSs. Mainly, it shall run fine at least on SunOS (Solaris), FreeBSD and Linux.

• Even if all previous ideas matches your demand, the author may not accept it based on the filter design requirements : it's own view of mail filters architecture, reliability, availability, security, … Sometimes this is a controversial domain, but hopefully different people in the world have the right to have its own ideas. In this case, the better is to ask the author of another filter to implement your request at his filter or eventually you can develop your own filter to implement your request.

ze-filter can intercept and quarantine messages not only for messages containing XFILES, but also spams. It could be insteresting to have some way to let users interact directly with quarantine and let them manage it. Quarantined files are let down inside /var/spool/ze-filter directory. Each quarantined messages generates an entry at /var/ze-filter/files/ze-xreport file : all data needed for quarantine management is logged there.

Basically, two programs are needed :

• A “summary message” generator : this program will be run once a day (p. ex.) and generate a report for each recipient having quarantined messages. This report contains a summary of the day activity and data enough to decide what to do with each quarantined message.
• A “quarantine management user interface” : this is a web interface allowing users to interact with its quarantined messages, retrieve false positives (both for spams and X-FILES).

Both programs are external to the filter itself.

If this interests you, you can contact the author or send a message to ze-filter forum to discuss specifications of these programs. It's a little bit more complicated than what's explained above, but the idea is there.

It could be possible to change configuration files format to XML. This way, it could be easy to create a web interface to manage all configuration files.

Managing user information in a mail gateway it's not that easy. All addresses seen by the filter aren't yet rewritten. Aliases, virtual users, … aren't easy to handle. Meanwhile, it's possible to, at some limited level, manage user preferences.

Learning the statistical filter isn't an easy task. I'm working on the possibility of distributing the tokens database in the same way as URLBL database - rsync. But databases depend from the community. As a first step, it could be nice to be able to distribute a tokens database for languages other than french.