Internet Messaging (“email”) is one of the oldest applications still supported 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. Proponents of work that is not taken up within the IETF may, of course, decide to bring their proposal to the Independent Stream. The working group should discuss such proposals with the ISE and share the results of the working group’s consideration. Further, MAILMAN will observe the following constraints when considering the adoption of new work directly: * Prior to any Call For Adoption of a document intended for the Standards Track 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. * When deciding to send any Standards Track work to the IESG, there must first be produced a report documenting at least two (preferably more) independent implementations with at least partial interoperation based on the developed specification. * 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. 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 the Independent Stream, and a record of the discussion in the working group’s mailing list will aid the IESG when conducting its conflict review if the ISE accepts the document.