Sections:

• Introduction
• Logic
• Parts

Introduction:

OpenBottle is a per user anti-spam email system based on a sender authenticated whitelist mechanism.

A quick example of a "normal" email transaction between the "sender" and the "recipient". The recipient is running OpenBottle.

• Sender sends mail to recipients email address.
• OpenBottle (as primary MX) receives email.
  • OpenBottle consults recipients whitelist.
  • OpenBottle sends a "verification request" bounce back to sender.
• Sender receives "verification request".
• Sender performs requested authentication action.
• OpenBottle passes correctly verified email onto original recipient.
  • OpenBottle stores sender in whitelist for later emails

OpenBottle is more than just the core logic and implementation of a whitelisting MTA. It needs to be a lot more. A user needs to be able to manage the whitelist, and so a user interfaces is required. There are other per-user requirements also: pending queues, verification options and other obscure nasties that a user has the right to be confused by. As such, OpenBottle has opted for PHP in the IMP/HORDE environment, with custom modifications to provide the added functionality.

As a necessity to test the entire system for function and usability OpenBottle is expected to be installed on a system with Cyrus IMAP also installed. It is possible to install the entire system on one machine (although this is not what it was specifically designed for.) Three, yes three differently configured sendmails are needed to get it running!

Logic:

This is pseudocode for the core logic within the OpenBottle MTA system.

foreach envelope {
    parse_headers;

    if (from_internal) {		// This is by authentication not domain!
        unalias_envfrom;
	btag_envfrom;			// We "tag" the Return-path
    }

    if (! to_internal) {
        deliver;
	next;
    }

    detag_envfrom;			
    if (envto_in_btaglist == "expired") {
        delete;
	next;
    } elsif (envto_in_btaglist) {	// Valid "tag" results in delivery.
        deliver;
	next;
    }

    if (verification_reply == "valid") {
    	user_white_list_add;
	delete;			
	next;
    } elsif (verification_reply == "invalid") {
        delete;
	next;
    }

    if (! rcpt_user_exists) {
        send_bounce;
	delete;
	next;
    }

    if (user_whitelist) {
    	deliver;
	next;
    }
    if (user_blacklist) {
    	delete;
	next;
    }
    send_verifiaction_request;
    set_message_pending;
}

Parts:

The parts that make up the running OpenBottle system (as it is implemented today) all need rather specific configuration to get up and running. There is an install script that tries to most of this, although the curious are reminded that this is pretty alpha stuff, and you will want to do any investigation on a "scratch box" that you can blow away after wrecking!

Note also that OpenBottle is more a proof-of-concept than anything, as such a lot of short-comings exist in the implementation (such as scalability, and efficiency). This can, of course, all be overcome with sufficient development time, and resources. Anybody interested in funding continued development?

• Sendmail(1) used as inbound MTA (primary MX).
• Message passed to OpenBottle.
• OpenBottle acts as a limited MTA (still requires sendmail).
• "Verification requests" (bounces) are sent via Sendmail(2) outbound MTA.
• Whitelisted senders are passed directly to Sendmail(2) outbound MTA.
• Sendmail(3) used as inbound MTA to Cyrus IMAP.
• OpenBottle consults OpenLDAP database for user whitelist, and other options.
• Webmail interface (horde/imp) consults Cyrus IMAP for authentication.
• Cyrus IMAP consults OpenLDAP via Cyrus SASL for authentication.

Again it is stressed that the implementation is not the most efficient, it was simply the fastest to develop. There are many techniques to make these mechanisms more efficient they just haven't been implemented.