Mail Maintenance (mailmaint) Internet Drafts

      
 SMTP Service Extension for Client Identity
 
 draft-storey-smtp-client-id-21.txt
 Date: 26/05/2026
 Authors: William Storey, Deion Yu, Shaun Johnson
 Working Group: Mail Maintenance (mailmaint)
 Multi-Factor Authentication has rapidly become a driving requirement for any internet based technology that requires authentication. While a large number of initiatives are active for providing solutions to this requirement for Web Browser based applications that can generally support real time human interaction for providing a secondary method of identification, legacy protocols such as SMTP authentication have not yet been revised to provide such support despite being a high-risk target for business email compromise, possibly as a result of authenticated SMTP activity generally expecting to be non-interactive in nature outside of Webmail logins. This document defines an extension to the SMTP service protocol called "CLIENTID" that a SMTP client can provide an additional unique identification token prior to standard credentials authentication that the server may then apply as an identify verification method in a similar manner to other Multi-Factor authentication techniques.
 IMAP Service Extension for Client Identity
 
 draft-yu-imap-client-id-16.txt
 Date: 26/05/2026
 Authors: Deion Yu, Shaun Johnson
 Working Group: Mail Maintenance (mailmaint)
 Multi-Factor Authentication has rapidly become a driving requirement for any internet based technology that requires authentication. While a large number of initiatives are active for providing solutions to this requirement for Web Browser based applications that can generally support real time human interaction for providing a secondary method of identification, legacy protocols such as [IMAP] have not yet been revised to provide such support despite being a high-risk target for business email compromise, possibly as a result of [IMAP] activity generally expecting to be non-interactive in nature outside of Webmail logins. This document defines an extension to the [IMAP] service protocol called "CLIENTID" that an [IMAP] client can provide an additional unique identification token prior to standard credentials authentication that the server may then apply as an identity verification method in a similar manner to other Multi-Factor authentication techniques.
 Updated Use of the Expires Message Header Field
 
 draft-ietf-mailmaint-expires-06.txt
 Date: 30/04/2026
 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.
 Mail Autoconfig
 
 draft-ietf-mailmaint-autoconfig-06.txt
 Date: 27/06/2026
 Authors: Ben Bucksch
 Working Group: Mail Maintenance (mailmaint)
 A protocol that allows email applications to set up mail accounts and related accounts with only the email address and password. It defines how service providers can publish the account configuration, so that email applications can automatically find a working configuration. It reduces setup friction for their users, and calls to the support for the service provider. Although the discovery process starts with an email address, the protocol is not limited setting up email accounts, but can also set up calendar, contact and file sync, video conference accounts and other accounts that are connected to the same user account. This protocol uses a well-known address and DNS lookups, based on the email address domain, to find the XML configuration file for the service provider.
 OAuth Profile for Open Public Clients
 
 draft-ietf-mailmaint-oauth-public-06.txt
 Date: 16/09/2026
 Authors: Neil Jenkins, Ben Bucksch
 Working Group: Mail Maintenance (mailmaint)
 This document specifies a profile of the OAuth authorization protocol to allow for interoperability between native clients and servers using open protocols, such as JMAP, IMAP, SMTP, POP, CalDAV, and CardDAV. The profile is restricted to native clients, that is, applications installed and run on the end user's device. It deliberately does not support web-based clients, which cannot complete the flow as specified.
 SMTPUTF8 Email Addresses
 
 draft-ietf-mailmaint-smtputf8-syntax-05.txt
 Date: 10/09/2026
 Authors: Arnt Gulbrandsen, Jiankang Yao
 Working Group: Mail Maintenance (mailmaint)
 RFC 6532 extends the internet email format to allow UTF8 in many contexts. This document restricts the set of allowed addresses in header fields slightly, and thereby simplifies use of these addresses. This is one of a pair of documents. This one is simple to implement and contains only globally viable rules. Its companion has more complex rules, takes regional usage into account, and describes addresses that can be read by some community and cut-and-pasted in some locale.
 Automatic Configuration of Email,Calendar,and Contact Server Settings
 
 draft-ietf-mailmaint-pacc-03.txt
 Date: 27/07/2026
 Authors: Daniel Eggert, Ben Bucksch, Matt Diephouse
 Working Group: Mail Maintenance (mailmaint)
 This document specifies an automatic configuration mechanism for email, calendar, and contact user agent applications. Service providers publish standardized configuration information that user agent applications retrieve and use to simplify server setup procedures.
 IMAP Extensions Suggestions
 
 draft-ietf-mailmaint-imap-extensions-suggestions-02.txt
 Date: 01/07/2026
 Authors: Ricardo Signes
 Working Group: Mail Maintenance (mailmaint)
 This document presents a set of IMAP extensions, each of which is recommended as a priority for general-purpose IMAP client and server implementations.
 Unobtrusive End-to-End Email Signatures
 
 draft-ietf-mailmaint-unobtrusive-signatures-02.txt
 Date: 30/04/2026
 Authors: Andrew Gallagher, Daniel Gillmor, Kai Engert
 Working Group: Mail Maintenance (mailmaint)
 This document deals with end-to-end cryptographically signed email. It introduces a structure for signed email that is designed to avoid creating any disturbance in legacy email clients. This "unobtrusive" signature structure removes disincentives for signing email.
 IMAP Extension for Object Identifiers
 
 draft-ietf-mailmaint-imap-objectid-bis-06.txt
 Date: 22/07/2026
 Authors: Bron Gondwana, Mauro De Gennaro
 Working Group: Mail Maintenance (mailmaint)
 This document defines the OBJECTID+ extension for IMAP, which obsoletes [RFC8474]. OBJECTID+ introduces a compound OBJECTID response format that bundles object identifiers into key-value pairs, an ACCOUNTID identifier for account-level context, OBJECTID response codes for the RENAME command, and identifier-based mailbox selection via SELECT and EXAMINE. The OBJECTID+ extension is activated implicitly when a client uses any OBJECTID+-specific feature, ensuring backward compatibility with clients that only support [RFC8474]. This document also updates [RFC9698]: when JMAPACCESS is advertised alongside OBJECTID+, ACCOUNTID values MUST correspond to JMAP accountIds.
 Personal Data Portability Archive
 
 draft-ietf-mailmaint-pdparchive-02.txt
 Date: 14/09/2026
 Authors: Hans-Joerg Happel, Lisa Dusseault, Alexey Melnikov
 Working Group: Mail Maintenance (mailmaint)
 This document proposes the Personal Data Portability Archive format (PDPA), suitable for import/export, backup/restore, and data transfer scenarios for personal data.

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

Mail Maintenance (mailmaint)

WG Name Mail Maintenance
Acronym mailmaint
Area Applications and Real-Time Area (art)
State Active
Charter charter-ietf-mailmaint-02 Approved
Document dependencies
Additional resources GitHub
Personnel Chairs Ken Murchison, Murray Kucherawy
Area Director Andy Newton
Mailing list Address [email protected]
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, nor are they applicable to administrative documents such as IANA registry actions.

  • 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
Nov 2026 Submit IMAP OBJECTID Bis draft draft-ietf-mailmaint-imap-objectid-bis
Nov 2026 Submit legacy Mail Autoconfig draft draft-ietf-mailmaint-autoconfig
Nov 2026 Submit PDP Archive draft
Nov 2026 Submit PACC draft draft-ietf-mailmaint-pacc
Jul 2026 Submit SMTPUTF8 addresses drafts draft-ietf-mailmaint-smtputf8-syntax
draft-ietf-mailmaint-interoperable-addresses
Jul 2026 Submit Wrong Recipient URL draft draft-ietf-mailmaint-wrong-recipient
Jul 2026 Submit IMAP Suggestions draft draft-ietf-mailmaint-imap-extensions-suggestions
Apr 2026 Submit OAuth profile for open clients draft draft-ietf-mailmaint-oauth-public

Done milestones

Date Milestone Associated documents
Done Submit Expires header field draft draft-ietf-mailmaint-expires
Done Adopt an IMAP OBJECTID ACCOUNTID draft draft-degennaro-imap-objectid-accountid
Done Adopt an email unubtrusive signatures draft draft-gallagher-email-unobtrusive-signatures
Done Submit IMAP keywords/attributes draft rfc9979 (was draft-ietf-mailmaint-messageflag-mailboxattribute)
Done Adopt IMAP OBJECTID Partial draft draft-gondwana-mailmaint-imap-objectid-partial
Done Adopt an IMAP suggestions draft draft-rjbs-mailmaint-imap-extensions-suggestions
Done Adopt a draft describing a new client autoconfig protocol draft-bucksch-mailmaint-pacc
Done Adopt a personal data portability archive draft draft-happel-mailmaint-pdparchive
Done Adopt an OAuth profile for open clients draft draft-jenkins-oauth-public
Done Adopt drafts registering currently used IMAP/JMAP keywords and mailbox attributes draft-eggert-mailflagcolors
draft-jenkins-mail-keywords
Done Adopt UIDBATCHES draft draft-eggert-uidbatches
Done Adopt drafts refining SMTPUTF8 addresses draft-gulbrandsen-smtputf8-nice-addresses
draft-gulbrandsen-smtputf8-syntax
Done Submit UIDBATCHES draft rfc10022 (was draft-ietf-mailmaint-imap-uidbatches)
Done Adopt a document describing legacy Mail Autoconfig draft-bucksch-autoconfig
Done Adopt a Wrong Recipient URL document draft-dweekly-wrong-recipient
Done Adopt a document for formalizing use of Expires header field in email draft-billon-expires

Not Adopted milestones

Date Milestone Associated documents
Not Adopted Adopt an IMAP WEBPUSH draft draft-gougeon-imap-webpush
Not Adopted Adopt an IMAP/SMTP Cient ID drafts draft-yu-imap-client-id
draft-storey-smtp-client-id