Mail Maintenance (mailmaint) Internet Drafts


      
 Updated Use of the Expires Message Header Field
 
 draft-ietf-mailmaint-expires-00.txt
 Date: 12/08/2024
 Authors: Benjamin BILLON, John Levine
 Working Group: Mail Maintenance (mailmaint)
This document allows broader use of the Expires message header field for mail messages. Message creators can then indicate when a message expires, while recipients would use this information to handle an expired message differently.
 Adding a Wrong Recipient URL for Handling Misdirected Emails
 
 draft-ietf-mailmaint-wrong-recipient-00.txt
 Date: 12/08/2024
 Authors: David Weekly
 Working Group: Mail Maintenance (mailmaint)
This document describes a mechanism for an email recipient to indicate to a sender that they are not the intended recipient.
 Mail Autoconfig
 
 draft-ietf-mailmaint-autoconfig-00.txt
 Date: 20/09/2024
 Authors: Ben Bucksch
 Working Group: Mail Maintenance (mailmaint)
Set up a mail account with only email address and password.


data-group-menu-data-url="/group/groupmenu.json">

Skip to main content

Mail Maintenance (mailmaint)

WG Name Mail Maintenance
Acronym mailmaint
Area Applications and Real-Time Area (art)
State Active
Charter charter-ietf-mailmaint-01 Approved
Document dependencies
Additional resources GitHub
Personnel Chair Kenneth Murchison
Area Director Murray Kucherawy
Mailing list Address mailmaint@ietf.org
To subscribe https://www.ietf.org/mailman/listinfo/mailmaint
Archive https://mailarchive.ietf.org/arch/browse/mailmaint/
Chat Room address https://zulip.ietf.org/#narrow/stream/mailmaint

Charter for Working Group

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.

(For the purposes of this charter, “email” starts in RFC 5321 which covers transport and RFC 5322 which covers message format, and extends into specifications based on those documents and their antecedents. It also includes related protocols such as IMAP [RFC 9051] and JMAP [RFC 8620, et seq].)

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 to publish 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 (ISE) without standards track status.

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.

Work proposed for MAILMAINT may arrive via direct proposals, or it may be referred via one or more DISPATCH-style working groups. Recorded Calls for Adoption are required for all work proposals.

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, MAILMAINT will observe the following constraints when considering the adoption of new work directly:

  • Prior to accepting any Standards Track document for development, 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.

  • The above constraints do not apply to documents that are not intended for the Standards Track.

  • Chartering of a dedicated working group with a custom charter is strongly preferred when engaging any work that updates any base email documents, including but not limited to those identified above.

All work will be announced to appropriate non-WG lists such as ietf-822, ietf-smtp, ietf-dkim, etc., at the time a Call For Adoption or Working Group Last Call begins.

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

Milestones will be used to track all approved work, including during chartering and rechartering.

Milestones

Date Milestone Associated documents
Feb 2025 WGLC on draft-ietf-mailmaint-expires draft-ietf-mailmaint-expires
Feb 2025 WGLC on draft-ietf-mailmaint-wrong-recipient draft-ietf-mailmaint-wrong-recipient
Jul 2024 Discuss where work on updating/clarifying SMTPUTF8 should be done draft-gulbrandsen-smtputf8-nice-addresses

Done milestones

Date Milestone Associated documents
Done Call for Adoption of draft-bucksch-autoconfig draft-bucksch-autoconfig
Done Call for Adoption of draft-billon-expires draft-billon-expires
Done Call For Adoption of draft-dweekly-wrong-recipient draft-dweekly-wrong-recipient