DELIVERABLES
Complete and fully-functional working program in executable form as well as complete source code of all work done. Specifically:
- Full source code
- Any make files, libraries, or compiler depenencies
- Installable XPI archive
- All scripts and makefiles required to build XPI archive
- Details of any external libraries used and sources

All deliverables will be considered "work made for hire" under U.S. Copyright law. Buyer will receive exclusive and complete copyrights to all work purchased. (No GPL, GNU, 3rd party components, etc. unless all copyright ramifications are explained AND AGREED TO by the buyer on the site per the coder's Seller Legal Agreement).

ACTIONS
When an email is selected, either in a list of emails or viewed as an individual email, the extension must offer two obvious choices, and a method for navigating to extension preferences.

The actions:
- Submit email as phish
- Check if email is a phish by checking individual URLs in email

Each will be described below. Both actions should be immediately available at all times the extension is installed and available.

INITIAL STATE
Either during extension installation, or immediately following extension installation, user must be prompted to enter their website username and API key, and provided a URL to retrieve (or create) that information at the website.

User should not be shown the Submit or Check actions until username and key are entered.

EXTENSION PREFS
At a minimum, extension must allow user to input and edit their website username and API key, and store user input so that username and key do not need to re-input repeatedly.

SUBMITTING EMAIL
When user chooses to submit (click or key command) an email as a potential phish via the extension, the extension must visually change state (design, language, or both) so the user knows their action is in progress/taking place.

Submitting means POSTing the full contents of an email, including all headers (critical), via the API. If the submission is rejected, the response accept code will be FALSE. If the submission is accepted, then a URL and ID also will be returned with the accept code TRUE.

Submitting will always be user-initiated. There are no automatic submissions.

CHECKING EMAIL
When a user chooses to check whether an email is a phish or not, the extension must visually change state (design, language, or both) so the user knows their action is in progress/taking place.

Checking means:
1. Parse the email locally for all URLs, eliminating duplicates.
2. Send all unique URLs via the API, one at a time. Response will be either TRUE, with a URL linking to the website details about the URL checked, or FALSE. If FALSE (meaning, not recognized), then extension should offer user option to Submit this email via the extension.

Checking will always be user-initiated. There are no automatic submissions.

ERROR HANDLING
If user is offline, the API is obviously not available. Extension should account for offline use. It is acceptable to simply show the user that the extension is not active/available if network status is down. If a user attempts to Submit or Check using the extension, and the call fails, either due to the user being offline or the API not responding within a reasonable threshold, then the extension should tell the user the action failed. The threshold depends on whether the extension requires a response before allowing the user to move on to their next task within Thunderbird. The API has a maximum time any request may take before it is killed on the server, but the extension may handle responses on its own schedule as long as the user interface is clear and consistent.

API INFORMATION
REST API has been completed, with documentation. You will be one of the early external users of this API; any delays incurred by documentation gaps will be accepted as long as communication is clear, direct, and speedy.

VISUAL DESIGN
Appropriate graphics (size and format) and language will be provided during development.

LOCATION
Open to developers anywhere in the world.

LANGUAGE
Extension will be offered initially in English. Separation of interface language from code, for future internationalization, is preferred.

EXPERIENCE
Ideally, you have already written either a Thunderbird or Firefox extension.

ATTRIBUTION
While we will own all the code and final product, we are happy to provide named attribution to the developer within the extension (probably within the Preferences screen, although location and language are at our discretion). Additionally, when promoting the extension, we will provide attribution to the developer on the website.

THUNDERBIRD INFO
http://www.mozilla.com/thunderbird/
https://addons.mozilla.org/thunderbird/extensions/
http://developer.mozilla.org/en/docs/Extensions

Extension must work with versions 1.5 and higher of Thunderbird, on all supported Thunderbird platforms.

Relevant RFCs for email are:
http://rfc.net/rfc2821.html - Simple Mail Transfer Protocol (critical for header information)
http://rfc.net/rfc2822.html - Internet Message Format

SIMILAR EXTENSIONS
These are not identical to what's desired, but may prove useful as examples.

Knujon
Okopipi and http://www.ibiblio.org/shadow/okopipi/