Email (historically "Internet Messaging") is one of the oldest applications still developed by the IETF.  It consists of numerous layers and extensions that support the robust construction, transport, retrieval, and interpretation of messages.

From time to time, new work in the email space is brought to the IETF for consideration and development.  Where there is enough critical mass to create a working group to develop and publish the work, this is the preferred case.  More often, however, a proposal is brought that lacks enough critical mass to independently support chartering of a working group, but would still be useful as a standard.  Such projects must then either seek the assent of an Area Director willing to sponsor it as a standards track document, or support via the Independent Stream Editor without standards track status.  But ADs are notoriously busy, and the ISE should not be considered a dumping ground or the option of last resort.

The MAILMAINT (“Mail Maintenance”) working group will consider projects in the email space that are too small to warrant construction of a dedicated working group.  This will take advantage of a common community to consider these proposals rather than forming a series of disparate but related communities.

Small administrative tasks, like mail-related media type registrations, may be adopted and processed directly, consulting the responsible Area Director for guidance where appropriate.

Proposed new work will be reviewed in the manner that the DISPATCH working group(s) observe, seeking to determine one of these possible outcomes:

* The work is appropriate to be done in the IETF, and the proposal is of broad enough scope that a dedicated working group is appropriate.  This may include support for writing a charter, planning and executing a Birds of a Feather session, or assisting an existing working group in extending its charter to accommodate the candidate work.

* The work is appropriate to be done in the IETF, and the proposal is narrow enough that it can be developed within the working group community directly.

* The work is appropriate for the IETF, but should be referred to the broader ALLDISPATCH working group for routing.

* The work is not appropriate for handling by the IETF.

The working group requires express approval from the supporting Area Director to adopt work directly.  All such work will be announced to appropriate lists such as ietf-822, ietf-smtp, ietf-dkim, etc.  Chartering of a dedicated working group with a custom charter is strongly preferred when engaging any work that updates the base email documents (RFC 5321 and RFC 5322 and their successors).

Proponents of work that is not taken up within the IETF may, of course, decide to bring their proposal to some other venue.  The working group should provide appropriate background and other support to other venues that agree to take up such work.

Further, MAILMAINT will observe the following constraints when considering the adoption of new work directly:

* Prior to passing any Standards Track document to the IESG, there must be a commitment to implement the resulting proposed standard from at least two independent parties, as recorded on a related IETF mailing list.  An interoperability demonstration will be preferred.

* Standards work being taken up by this working group should be checked with other relevant areas (mainly Security) to confirm appropriate oversight or possible assignment to that area.

* Engaging historical "indigestible dumpling" topics, such as the definition of trace fields, shall be avoided, and such work deferred to other venues.

The working group will not accept for processing any documents that describe something already in practice that was not developed with IETF consensus, except in cases where change control is fully transferred to the IETF.  Such work can otherwise be taken by its proponents to other venues, as discussed above.