SummerOfCode2005/SergeyLubinskiyFastFail

Hello!

I'm Sergey Lubinskiy. I study at http://www.msu.ru/en/ department of physics. I'm keen of programming. Although I don't specialize in it I posses a considerable load of knowledge on Java and internet. I like hacking hiking and bike-riding

My friends think that I tend to think and code a bit too academically. But I hope this will only help me to participate in the summer of code program. Here's my proposal.

Problem

James mail server performs reasonably well under normal load. Heavy spam and virus traffic or dos attacks can significantly degrade its performance. Under the current design we can not discard SMTP message until it has been completely recieved and saved to filesystem or database. Combating spam requires us to adopt an alternative strategy - cut TCP connections judging on senders IP, RCPT, FROM and alike without even looking inside the message.

Another issue is that under the current design very little control is possible over a running instance of James mail server - the main configuration method is to edit configuration manually and then restart (which takes significant time).

Proposed solutions

Following FastFail proposal by DannyAngus and NoelBergman I intend to implement a drop-in replacement for SMTPServer block - the New SMTP Block.

The New SMTP Block will be close in design to JamesSpoolManager:

• JamesSpoolManager hosts a family of (matcher mailet) pairs

• The New SMTP Block will host a sequence of ./ProtocolLet s.

POJO/JMX/XML Configuration Convergence

One of the key features of the proposed ./ProtocolLet desing is a rich runtime configuration model. The New SMTP Block will be able to

• read/write configuration of each ./ProtocolLet in XML format

• expose all of the ./ProtocolLet s as managed beans

• for each of ./ProtoclLet s' managed beans provide a JMX attribute for setting and getter configuration

• expose JMX operations for reordering ./ProtocolLet s taking them down and creating new ones

All the metadata about a ./ProtocolLet will be extracted by introspecting the implementating class. Both XML format and JMX interface will be derived products.

ProtocolLets As A New Kind Of Components

Similar to Regular Phoenix Blocks ./ProtocolLet s will be able to depend on other Blocks inside James Phoenix Application.

Future Directions

If timeframe permits I may try to implement integration with scripting languages. There's nothing impossible in ./ProtocolLet s being written in BeanShell, Jython, JavaScript.

Advantages for ASF

• A solid foundation for RBL/SPF/white-gray listing/Fill-In-Yours FastFail spam blocking

• Possibly a new insight on COP via POJO/XML/JMX configuration convergence

Deliverables

• Totally revamped drop-in replacement for the existing SMTPServer

• Possibly patches for ASF COP containers.

Open Source Software Used

Apache Phoenix, JUnit, MX4J, MC4J, in the optimistic scenario BeanShell, Jython, JavaScript.

Schedule