Features/Thunderbird/Modern MIME Parser

Status

Team

Open issues/risks

`

Stage 1: Definition

1. Feature overview

The current implementation of libmime is not maintainable, by combination of the library pushing the entire stack from parsing to display management logic into one single system and the implementation in an obfuscatory style of C. The goal of this project is to provide a new implementation of the parsing logic which is more accessible to other people.

2. Users & use cases

The new implementation should be easily usable and drivable from JS, and have at least a usable API from C++. These are the kinds of tasks we envision supporting: 1. Use in the fakeservers where understanding MIME is necessary 2. Things like Gloda that need an accurate representation of the MIME tree

3. Dependencies

`

4. Requirements

`

Non-goals

This feature is intended to eventually replace libmime in the long run. However, replacing the current code in libmime is not a goal in this iteration.

In this iteration, the following features will be unsupported to keep the implementation manageable: 1. RFC 2047/RFC 2231 decoding (all i18n concerns, basically) 2. Support for uuencode, yEnc, S/MIME, PGP

Stage 2: Design

5. Functional specification

`

6. User experience design

`

Stage 3: Planning

7. Implementation plan

`

8. Reviews

Security review

A MIME fuzzer should be developed at some part in this process.

Privacy review

`

Localization review

l10n and i18n are explicit non-goals for now.

Accessibility

`

Quality Assurance review

We need some way of checking that the new parser and libmime return the same results.

Operations review

`

Stage 4: Development

9. Implementation

`

Stage 5: Release

10. Landing criteria

`

Feature details

Team status notes