CINXE.COM

draft-ietf-extra-imap-messagelimit-10 - IMAP MESSAGELIMIT Extension

<!DOCTYPE html> <html data-bs-theme="auto" lang="en" prefix="og: http://ogp.me/ns# article: http://ogp.me/ns/article#"> <head> <meta charset="utf-8"> <meta http-equiv="X-UA-Compatible" content="IE=edge"> <title> draft-ietf-extra-imap-messagelimit-10 - IMAP MESSAGELIMIT Extension </title> <meta name="viewport" content="width=device-width, initial-scale=1"> <link href="https://static.ietf.org/fonts/inter/import.css" rel="stylesheet"> <link href="https://static.ietf.org/fonts/noto-sans-mono/import.css" rel="stylesheet"> <link rel="stylesheet" href="https://static.ietf.org/dt/12.28.2/ietf/css/ietf.css"> <link rel="stylesheet" href="https://static.ietf.org/dt/12.28.2/ietf/css/select2.css"> <script src="https://static.ietf.org/dt/12.28.2/ietf/js/theme.js"></script> <style> .inline { display: inline; } </style> <meta property="og:title" content="IMAP MESSAGELIMIT Extension"> <meta property="og:url" content="https://datatracker.ietf.org/doc/draft-ietf-extra-imap-messagelimit/"> <link rel="canonical" href="https://datatracker.ietf.org/doc/draft-ietf-extra-imap-messagelimit/"> <meta property="og:site_name" content="IETF Datatracker"> <meta property="og:description" content="The MESSAGELIMIT extension of the Internet Message Access Protocol (RFC 3501/RFC 9051) allows servers to announce a limit on the number of messages that can be processed in a single FETCH/SEARCH/STORE/COPY/MOVE (or their UID variants), APPEND or UID EXPUNGE command. This helps servers to control resource usage when performing various IMAP operations. This helps clients to know the message limit enforced by corresponding IMAP server and avoid issuing commands that would exceed such limit."> <meta property="og:type" content="article"> <meta property="og:image" content="https://static.ietf.org/dt/12.28.2/ietf/images/ietf-logo-card.png"> <meta property="og:image:alt" content="Logo of the IETF"> <meta property="article:section" content="IETF - Internet Engineering Task Force"> <meta property="og:image:type" content="image/png"> <meta property="og:image:width" content="1200"> <meta property="og:image:height" content="630"> <meta name="twitter:card" content="summary_large_image"> <meta property="article:author" content="Alexey Melnikov"> <meta property="article:author" content="ArunPrakash Achuthan"> <meta property="article:author" content="Vikram Nagulakonda"> <meta property="article:author" content="Luis Alves"> <link rel="alternate" type="application/atom+xml" title="Document changes" href="/feed/document-changes/draft-ietf-extra-imap-messagelimit/"> <meta name="description" content="IMAP MESSAGELIMIT Extension "> <script type="module" crossorigin="" src="https://static.ietf.org/dt/12.28.2/assets/embedded-e653257c.js"></script> <link href="https://static.ietf.org/dt/12.28.2/assets/create-pinia-singleton-091c62b7.js" type="text/javascript" crossorigin="anonymous" rel="modulepreload" as="script" /> <link href="https://static.ietf.org/dt/12.28.2/assets/Scrollbar-7de50899.js" type="text/javascript" crossorigin="anonymous" rel="modulepreload" as="script" /> <link rel="apple-touch-icon" sizes="180x180" href="https://static.ietf.org/dt/12.28.2/ietf/images/ietf-logo-nor-180.png"> <link rel="icon" sizes="32x32" href="https://static.ietf.org/dt/12.28.2/ietf/images/ietf-logo-nor-32.png"> <link rel="icon" sizes="16x16" href="https://static.ietf.org/dt/12.28.2/ietf/images/ietf-logo-nor-16.png"> <link rel="manifest" href="/site.webmanifest"> <link rel="mask-icon" href="https://static.ietf.org/dt/12.28.2/ietf/images/ietf-logo-nor-mask.svg" color="#ffffff"> <meta name="msapplication-TileColor" content="#ffffff"> <meta name="theme-color" content="#ffffff"> <script src="https://static.ietf.org/dt/12.28.2/ietf/js/ietf.js"></script> </head> <body class="navbar-offset position-relative" data-group-menu-data-url="/group/groupmenu.json"> <noscript><iframe class="status" title="Site status" src="/status/latest"></iframe></noscript> <div class="vue-embed" data-component="Status"></div> <a class="visually-hidden visually-hidden-focusable" href="#content">Skip to main content</a> <nav class="navbar navbar-expand-lg fixed-top bg-secondary-subtle"> <div class="container-fluid"> <a class="navbar-brand" href="/"> <img alt="IETF Logo" class="d-lm-none me-2" src="https://static.ietf.org/dt/12.28.2/ietf/images/ietf-logo-nor-white.svg" > <img alt="IETF Logo" class="d-dm-none me-2" src="https://static.ietf.org/dt/12.28.2/ietf/images/ietf-logo-nor.svg" > Datatracker </a> <div class="collapse navbar-collapse" id="navbar-collapse"> <ul class="nav navbar-nav flex-nowrap"> <li class="nav-item dropdown"> <a href="#" class="nav-link dropdown-toggle" role="button" data-bs-toggle="dropdown" aria-expanded="false"> Groups </a> <ul class="dropdown-menu mt-n1"> <li class="dropdown-header">By area/parent</li> <li class="dropend group-menu group-parent-2010"> <a class="dropdown-item dropdown-toggle " href="/wg/#ART"> Apps &amp; Realtime </a> </li> <li class="dropend group-menu group-parent-1008"> <a class="dropdown-item dropdown-toggle " href="/wg/#GEN"> General </a> </li> <li class="dropend group-menu group-parent-1052"> <a class="dropdown-item dropdown-toggle " href="/wg/#INT"> Internet </a> </li> <li class="dropend group-menu group-parent-1193"> <a class="dropdown-item dropdown-toggle " href="/wg/#OPS"> Ops &amp; Management </a> </li> <li class="dropend group-menu group-parent-1249"> <a class="dropdown-item dropdown-toggle " href="/wg/#RTG"> Routing </a> </li> <li class="dropend group-menu group-parent-1260"> <a class="dropdown-item dropdown-toggle " href="/wg/#SEC"> Security </a> </li> <li class="dropend group-menu group-parent-2412"> <a class="dropdown-item dropdown-toggle " href="/wg/#WIT"> Web and Internet Transport </a> </li> <li class="dropend group-menu group-parent-7"> <a class="dropdown-item dropdown-toggle " href="/program/"> IAB </a> </li> <li class="dropend group-menu group-parent-3"> <a class="dropdown-item dropdown-toggle " href="/rg/"> IRTF </a> </li> <li class="dropend group-menu group-parent-2309"> <a class="dropdown-item dropdown-toggle " href="/adm/"> IETF LLC </a> </li> <li class="dropend group-menu group-parent-1876"> <a class="dropdown-item dropdown-toggle " href="/rfcedtyp/"> RFC Editor </a> </li> <li class="dropend"> <a class="dropdown-item dropdown-toggle " href="/group/"> Other </a> <ul class="dropdown-menu ms-n1"> <li> <a class="dropdown-item " href="/ag/">Active AGs</a> </li> <li> <a class="dropdown-item " href="/area/">Active Areas</a> </li> <li> <a class="dropdown-item " href="/dir/">Active Directorates</a> </li> <li> <a class="dropdown-item " href="/iabworkshop/">Active IAB Workshops</a> </li> <li> <a class="dropdown-item " href="/program/">Active Programs</a> </li> <li> <a class="dropdown-item " href="/rag/">Active RAGs</a> </li> <li> <a class="dropdown-item " href="/team/">Active Teams</a> </li> </ul> </li> <li><hr class="dropdown-divider"></li> <li class="dropdown-header">New work</li> <li> <a class="dropdown-item " href="/group/chartering/"> Chartering groups </a> </li> <li> <a class="dropdown-item " href="/wg/bofs/"> BOFs </a> </li> <li> <a class="dropdown-item " href="/doc/bof-requests"> BOF Requests </a> </li> <li><hr class="dropdown-divider"></li> <li class="dropdown-header">Other groups</li> <li> <a class="dropdown-item " href="/group/concluded/"> Concluded groups </a> </li> <li> <a class="dropdown-item " href="/list/nonwg"> Non-WG lists </a> </li> </ul> </li> <li class="nav-item dropdown"> <a href="#" class="nav-link dropdown-toggle" role="button" data-bs-toggle="dropdown" aria-expanded="false"> Documents </a> <ul class="dropdown-menu mt-n1"> <li> <a class="dropdown-item " href="/doc/search"> Search </a> </li> <li> <a class="dropdown-item " href="/doc/recent"> Recent I-Ds </a> </li> <li> <a class="dropdown-item " href="/submit/"> I-D submission </a> </li> <li> <a class="dropdown-item " href="/doc/ad"> IESG dashboard </a> </li> <li><hr class="dropdown-divider"> </li> <li class="dropdown-header"> RFC streams </li> <li> <a class="dropdown-item " href="/stream/iab/"> IAB </a> </li> <li> <a class="dropdown-item " href="/stream/irtf/"> IRTF </a> </li> <li> <a class="dropdown-item " href="/stream/ise/"> ISE </a> </li> <li> <a class="dropdown-item " href="/stream/editorial/"> Editorial </a> </li> <li><hr class="dropdown-divider"> </li> <li class="dropdown-header"> Subseries </li> <li> <a class="dropdown-item " href="/doc/std"> STD </a> <a class="dropdown-item " href="/doc/bcp"> BCP </a> <a class="dropdown-item " href="/doc/fyi"> FYI </a> </li> </ul> </li> <li class="nav-item dropdown"> <a href="#" class="nav-link dropdown-toggle" role="button" data-bs-toggle="dropdown" aria-expanded="false"> Meetings </a> <ul class="dropdown-menu mt-n1"> <li> <a class="dropdown-item " href="/meeting/agenda"> Agenda </a> </li> <li> <a class="dropdown-item " href="/meeting/materials"> Materials </a> </li> <li> <a class="dropdown-item " href="/meeting/floor-plan"> Floor plan </a> </li> <li> <a class="dropdown-item " href="https://www.ietf.org/how/meetings/register/"> Registration </a> </li> <li> <a class="dropdown-item " href="/meeting/important-dates/"> Important dates </a> </li> <li> <a class="dropdown-item " href="/secr/sreq/"> Request a session </a> </li> <li> <a class="dropdown-item " href="/meeting/requests"> Session requests </a> </li> <li><hr class="dropdown-divider"> </li> <li class="dropdown-header"> Upcoming meetings </li> <li> <a class="dropdown-item " href="/meeting/upcoming"> Upcoming meetings </a> </li> <li><hr class="dropdown-divider"> </li> <li class="dropdown-header"> Past meetings </li> <li> <a class="dropdown-item " href="/meeting/past"> Past meetings </a> </li> <li> <a class="dropdown-item " href="https://www.ietf.org/how/meetings/past/"> Meeting proceedings </a> </li> </ul> </li> <li class="nav-item dropdown"> <a href="#" class="nav-link dropdown-toggle" role="button" data-bs-toggle="dropdown" aria-expanded="false"> Other </a> <ul class="dropdown-menu mt-n1"> <li> <a class="dropdown-item " href="/ipr/"> IPR disclosures </a> </li> <li> <a class="dropdown-item " href="/liaison/"> Liaison statements </a> </li> <li> <a class="dropdown-item " href="/iesg/agenda/"> IESG agenda </a> </li> <li> <a class="dropdown-item " href="/nomcom/"> NomComs </a> </li> <li> <a class="dropdown-item " href="/doc/downref"> Downref registry </a> </li> <li> <a class="dropdown-item " href="/stats/"> Statistics </a> <ul class="dropdown-menu mt-n1"> <li> <a class="dropdown-item " href="/stats/document/"> I-Ds/RFCs </a> </li> <li> <a class="dropdown-item " href="/stats/meeting/"> Meetings </a> </li> </ul> </li> <li> <a class="dropdown-item " href="/api/"> API Help </a> </li> <li> <a class="dropdown-item " href="/release/"> Release notes </a> </li> <li> <a class="dropdown-item " target="_blank" href="https://status.ietf.org"> System status </a> </li> <li><hr class="dropdown-divider"> </li> <li> <a class="dropdown-item text-danger " target="_blank" href="https://github.com/ietf-tools/datatracker/issues/new/choose"> <i class="bi bi-bug"> </i> Report a bug </a> </li> </ul> </li> <li class="nav-item dropdown"> <a href="#" class="nav-link dropdown-toggle" role="button" data-bs-toggle="dropdown" aria-expanded="false"> User </a> <ul class="dropdown-menu mt-n1 "> <li> <a class="dropdown-item " rel="nofollow" href="/accounts/login/?next=/doc/draft-ietf-extra-imap-messagelimit/"> Sign in </a> </li> <li> <a class="dropdown-item " rel="nofollow" href="/accounts/reset/"> Password reset </a> </li> <li> <a class="dropdown-item " href="/accounts/settings/" rel="nofollow"> Preferences </a> </li> <li> <a class="dropdown-item " href="/accounts/create/"> New account </a> </li> </ul></li> </ul> </div> <div class="d-flex align-items-center"> <a class="nav-link text-danger d-none d-xl-inline me-xl-4" target="_blank" href="https://github.com/ietf-tools/datatracker/issues/new/choose"> Report a bug <i class="bi bi-bug"></i> </a> <a class="btn me-1 btn-warning d-none d-sm-block" rel="nofollow" href="/accounts/login/?next=/doc/draft-ietf-extra-imap-messagelimit/"> Sign in </a> <label class="d-none d-md-block" aria-label="Document search"> <input class="form-control select2-field search-select" id="navbar-doc-search" data-select2-ajax-url="/doc/select2search/document/all/" type="text" data-placeholder="Document search"> </label> </div> <button class="navbar-toggler" type="button" data-bs-toggle="collapse" data-bs-target="#navbar-collapse" aria-controls="navbar-collapse" aria-expanded="false" aria-label="Toggle navigation"> <i class="navbar-toggler-icon"></i> </button> </div> </nav> <main class="pt-3 container-fluid" id="main"> <div class="row"> <div class="col mx-lg-3 ietf-auto-nav" id="content"> <noscript> <div class="alert alert-danger alert-ignore my-3"> <b>Javascript disabled?</b> Like other modern websites, the IETF Datatracker relies on Javascript. Please enable Javascript for full functionality. </div> </noscript> <h1> IMAP MESSAGELIMIT Extension <br> <small class="text-body-secondary">draft-ietf-extra-imap-messagelimit-10</small> </h1> <ul class="nav nav-tabs my-3"> <li class="nav-item"> <a class="nav-link active" href="/doc/draft-ietf-extra-imap-messagelimit/"> Status </a> </li> <li class="nav-item"> <a class="nav-link " href="/doc/draft-ietf-extra-imap-messagelimit/ballot/"> IESG evaluation record </a> </li> <li class="nav-item"> <a class="nav-link " href="/doc/draft-ietf-extra-imap-messagelimit/writeup/"> IESG writeups </a> </li> <li class="nav-item"> <a class="nav-link " href="/doc/draft-ietf-extra-imap-messagelimit/email/"> Email expansions </a> </li> <li class="nav-item"> <a class="nav-link " href="/doc/draft-ietf-extra-imap-messagelimit/history/"> History </a> </li> </ul> <label class="my-1 fw-bold">Versions:</label> <nav class="mb-3"> <ul class="revision-list pagination pagination-sm text-center flex-wrap"> <li class="page-item "> <a class="page-link" href="/doc/draft-ietf-extra-imap-messagelimit/00/" > 00 </a> </li> <li class="page-item "> <a class="page-link" href="/doc/draft-ietf-extra-imap-messagelimit/01/" rel="nofollow"> 01 </a> </li> <li class="page-item "> <a class="page-link" href="/doc/draft-ietf-extra-imap-messagelimit/02/" rel="nofollow"> 02 </a> </li> <li class="page-item "> <a class="page-link" href="/doc/draft-ietf-extra-imap-messagelimit/03/" rel="nofollow"> 03 </a> </li> <li class="page-item "> <a class="page-link" href="/doc/draft-ietf-extra-imap-messagelimit/04/" rel="nofollow"> 04 </a> </li> <li class="page-item "> <a class="page-link" href="/doc/draft-ietf-extra-imap-messagelimit/05/" rel="nofollow"> 05 </a> </li> <li class="page-item "> <a class="page-link" href="/doc/draft-ietf-extra-imap-messagelimit/06/" rel="nofollow"> 06 </a> </li> <li class="page-item "> <a class="page-link" href="/doc/draft-ietf-extra-imap-messagelimit/07/" rel="nofollow"> 07 </a> </li> <li class="page-item "> <a class="page-link" href="/doc/draft-ietf-extra-imap-messagelimit/08/" rel="nofollow"> 08 </a> </li> <li class="page-item "> <a class="page-link" href="/doc/draft-ietf-extra-imap-messagelimit/09/" rel="nofollow"> 09 </a> </li> <li class="page-item active"> <a class="page-link" href="/doc/draft-ietf-extra-imap-messagelimit/10/" > 10 </a> </li> </ul> </nav> <div id="doc-timeline"></div> <table class="table table-sm table-borderless"> <tbody class="meta align-top border-top"> <tr> <th scope="row">Document</th> <th scope="row">Type</th> <td class="edit"></td> <td> <span class="text-success">Active Internet-Draft</span> (<a href="/wg/extra/about/">extra WG</a>) </td> </tr> <tr> <td></td> <th scope="row">Authors</th> <td class="edit"> </td> <td> <span ><a title="Datatracker profile of Alexey Melnikov" href="/person/alexey.melnikov@isode.com" >Alexey Melnikov</a> <a href="mailto:alexey.melnikov%40isode.com" aria-label="Compose email to alexey.melnikov@isode.com" title="Compose email to alexey.melnikov@isode.com"> <i class="bi bi-envelope"></i></a></span>, <span ><a title="Datatracker profile of ArunPrakash Achuthan" href="/person/mail2arunprakash@yahoo.com" >ArunPrakash Achuthan</a> <a href="mailto:mail2arunprakash%40yahoo.com" aria-label="Compose email to mail2arunprakash@yahoo.com" title="Compose email to mail2arunprakash@yahoo.com"> <i class="bi bi-envelope"></i></a></span>, <span ><a title="Datatracker profile of Vikram Nagulakonda" href="/person/nvikram_imap@yahoo.com" >Vikram Nagulakonda</a> <a href="mailto:nvikram_imap%40yahoo.com" aria-label="Compose email to nvikram_imap@yahoo.com" title="Compose email to nvikram_imap@yahoo.com"> <i class="bi bi-envelope"></i></a></span>, <span ><a title="Datatracker profile of Luis Alves" href="/person/luis.alves@lafaspot.com" >Luis Alves</a> <a href="mailto:luis.alves%40lafaspot.com" aria-label="Compose email to luis.alves@lafaspot.com" title="Compose email to luis.alves@lafaspot.com"> <i class="bi bi-envelope"></i></a></span> </td> </tr> <tr> <td></td> <th scope="row">Last updated</th> <td class="edit"></td> <td> 2024-11-18 <span class="text-body-secondary">(Latest revision 2024-07-29)</span> </td> </tr> <tr> <td></td> <th scope="row"> RFC stream </th> <td class="edit"> </td> <td > Internet Engineering Task Force (IETF) </td> </tr> <tr> <td></td> <th scope="row"> Intended RFC status </th> <td class="edit"> </td> <td> Experimental </td> </tr> <tr> <td></td> <th scope="row"> Formats </th> <td class="edit"> </td> <td> <div class="buttonlist"> <a class="btn btn-primary btn-sm" target="_blank" href="https://www.ietf.org/archive/id/draft-ietf-extra-imap-messagelimit-10.txt"> <i class="bi bi-file-text"></i> txt </a> <a class="btn btn-primary btn-sm" target="_blank" href="https://www.ietf.org/archive/id/draft-ietf-extra-imap-messagelimit-10.html"> <i class="bi bi-file-code"></i> html </a> <a class="btn btn-primary btn-sm" target="_blank" href="https://www.ietf.org/archive/id/draft-ietf-extra-imap-messagelimit-10.xml"> <i class="bi bi-file-code"></i> xml </a> <a class="btn btn-primary btn-sm" href="/doc/html/draft-ietf-extra-imap-messagelimit-10"> <i class="bi bi-file-code"></i> htmlized </a> <a class="btn btn-primary btn-sm" target="_blank" href="/doc/draft-ietf-extra-imap-messagelimit/10/bibtex/"> <i class="bi bi-file-ruled"></i> bibtex </a> <a class="btn btn-primary btn-sm" target="_blank" href="/doc/bibxml3/draft-ietf-extra-imap-messagelimit-10.xml"> <i class="bi bi-file-code"></i> bibxml </a> </div> </td> </tr> <tr> <td></td> <th scope="row"> Reviews </th> <td class="edit"> </td> <td> <div class="review-assignment-summary"> <a href="/doc/review-ietf-extra-imap-messagelimit-10-artart-telechat-leiba-2024-08-01/"> ARTART Telechat review by Barry Leiba</a> <span class="badge rounded-pill text-bg-success text-wrap"> <i class="bi bi-"></i> Ready </span> </div> <div class="review-assignment-summary"> <a href="/doc/review-ietf-extra-imap-messagelimit-08-secdir-lc-moriarty-2024-05-31/"> SECDIR Last Call review (of -08) by Kathleen Moriarty</a> <span class="badge rounded-pill text-bg-success text-wrap"> <i class="bi bi-"></i> Ready </span> </div> <div class="review-assignment-summary"> <a href="/doc/review-ietf-extra-imap-messagelimit-08-genart-lc-housley-2024-03-08/"> GENART Last Call review (of -08) by Russ Housley</a> <span class="badge rounded-pill text-bg-success text-wrap"> <i class="bi bi-"></i> Ready </span> </div> <div class="review-assignment-summary"> <a href="/doc/review-ietf-extra-imap-messagelimit-08-opsdir-lc-jaeggli-2024-03-12/"> OPSDIR Last Call review (of -08) by Joel Jaeggli</a> <span class="badge rounded-pill text-bg-success text-wrap"> <i class="bi bi-"></i> Ready </span> </div> <div class="review-assignment-summary"> <a href="/doc/review-ietf-extra-imap-messagelimit-08-artart-lc-leiba-2024-03-13/"> ARTART Last Call review (of -08) by Barry Leiba</a> <span class="badge rounded-pill text-bg-success text-wrap"> <i class="bi bi-"></i> Ready w/issues </span> </div> </td> </tr> <tr> <td> </td> <th scope="row"> Additional resources </th> <td class="edit"> </td> <td> <a href="https://mailarchive.ietf.org/arch/browse/extra/?q=draft-ietf-extra-imap-messagelimit"> Mailing list discussion </a> </td> </tr> </tbody> <tbody class="meta border-top"> <tr> <th scope="row"> Stream </th> <th scope="row"> <a href="/doc/help/state/draft-stream-ietf/"> WG state </a> </th> <td class="edit"> </td> <td> <span class=""> Submitted to IESG for Publication </span> </td> </tr> <tr> <td></td> <th scope="row"> Associated WG milestone</th> <td class="edit"></td> <td> <dl class="row"> <dt class="col-sm-2 my-0">Dec 2023</dt> <dd class="col-sm-10 my-0">Submit MESSAGELIMIT draft</dd> </dl> </td> </tr> <tr> <td></td> <th scope="row"> Document shepherd </th> <td class="edit"> </td> <td> <span ><a title="Datatracker profile of Bron Gondwana" href="/person/brong@fastmailteam.com" >Bron Gondwana</a> <a href="mailto:brong%40fastmailteam.com" aria-label="Compose email to brong@fastmailteam.com" title="Compose email to brong@fastmailteam.com"> <i class="bi bi-envelope"></i></a></span> </td> </tr> <tr> <td></td> <th scope="row"> Shepherd write-up </th> <td class="edit"> </td> <td> <a class="btn btn-primary btn-sm" href="/doc/draft-ietf-extra-imap-messagelimit/shepherdwriteup/"> Show </a> <span class="badge rounded-pill text-bg-secondary">Last changed 2024-02-01</span> </td> </tr> </tbody> <tbody class="meta border-top"> <tr> <th scope="row"> IESG </th> <th scope="row"> <a href="/doc/help/state/draft-iesg/"> IESG state </a> </th> <td class="edit"> </td> <td> <span class=""> RFC Ed Queue </span> </td> </tr> <tr> <td></td> <th scope="row"> Action Holders </th> <td class="edit"> </td> <td> <div> <span class="text-body-secondary"> (None) </span> </div> </td> </tr> <tr> <td></td> <th scope="row"> Consensus boilerplate </th> <td class="edit"> </td> <td> <span class="text-success" title="Whether the document is the result of a community consensus process as defined in RFC 5741"> Yes </span> </td> </tr> <tr> <td></td> <th scope="row"> Telechat date </th> <td class="edit"> </td> <td> <span class="text-body-secondary"> (None) </span> </td> </tr> <tr> <td></td> <th scope="row"> Responsible AD </th> <td class="edit"> </td> <td> <span ><a title="Datatracker profile of Murray Kucherawy" href="/person/superuser@gmail.com" >Murray Kucherawy</a> <a href="mailto:superuser%40gmail.com" aria-label="Compose email to superuser@gmail.com" title="Compose email to superuser@gmail.com"> <i class="bi bi-envelope"></i></a></span> </td> </tr> <tr> <td></td> <th scope="row"> Send notices to </th> <td class="edit"> </td> <td> <a href="mailto:arnt.gulbrandsen@icann.org">arnt.gulbrandsen@icann.org</a>, <a href="mailto:brong@fastmailteam.com">brong@fastmailteam.com</a> </td> </tr> </tbody> <tbody class="meta border-top"> <tr> <th scope="row"> IANA </th> <th scope="row"> <a href="/doc/help/state/draft-iana-review/"> IANA review state </a> </th> <td class="edit"> </td> <td class="text-success"> IANA OK - Actions Needed </td> </tr> <tr> <th scope="row"> </th> <th scope="row"> <a href="/doc/help/state/draft-iana-action/"> IANA action state </a> </th> <td class="edit"> </td> <td> Waiting on Authors </td> </tr> </tbody> <tbody class="meta border-top"> <tr> <th scope="row"> RFC Editor </th> <th scope="row"> <a href="/doc/help/state/draft-rfceditor/"> RFC Editor state </a> </th> <td class="edit"> </td> <td> EDIT </td> </tr> <tr> <td></td> <th scope="row"> Details </th> <td class="edit"> </td> <td> <div> <a href="https://www.rfc-editor.org/queue2.html#draft-ietf-extra-imap-messagelimit"> Publication queue entry </a> </div> </td> </tr> </tbody> </table> <div class="buttonlist"> <a class="btn btn-primary btn-sm" href="mailto:draft-ietf-extra-imap-messagelimit@ietf.org?subject=Mail%20regarding%20draft-ietf-extra-imap-messagelimit"> <i class="bi bi-envelope"> </i> Email authors </a> <a class="btn btn-primary btn-sm" href="mailto:extra@ietf.org?subject=Mail%20regarding%20draft-ietf-extra-imap-messagelimit"> <i class="bi bi-envelope"> </i> Email WG </a> <a class="btn btn-primary btn-sm" href="/ipr/search/?submit=draft&amp;id=draft-ietf-extra-imap-messagelimit" rel="nofollow"> <i class="bi bi-lightning"> </i> IPR </a> <a class="btn btn-primary btn-sm" href="/doc/draft-ietf-extra-imap-messagelimit/references/" rel="nofollow"> <i class="bi bi-arrow-left"> </i> References </a> <a class="btn btn-primary btn-sm" href="/doc/draft-ietf-extra-imap-messagelimit/referencedby/" rel="nofollow"> <i class="bi bi-arrow-right"> </i> Referenced by </a> <a class="btn btn-primary btn-sm" href="https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-extra-imap-messagelimit-10.txt" rel="nofollow" target="_blank"> <i class="bi bi-exclamation"> </i> Nits </a> <a class="btn btn-primary btn-sm" href="https://mailarchive.ietf.org/arch/search/?q=%22draft-ietf-extra-imap-messagelimit%22" rel="nofollow" target="_blank"> <i class="bi bi-search"> </i> Search email archive </a> </div> <div class="card mt-5"> <div class="card-header"> draft-ietf-extra-imap-messagelimit-10 </div> <div class="card-body"> <pre>Network Working Group A. Melnikov Internet-Draft Isode Intended status: Experimental A. P. Achuthan Expires: 30 January 2025 V. Nagulakonda Yahoo! L. Alves 29 July 2024 IMAP MESSAGELIMIT Extension draft-ietf-extra-imap-messagelimit-10 <span>Abstract</span> The MESSAGELIMIT extension of the Internet Message Access Protocol (RFC 3501/RFC 9051) allows servers to announce a limit on the number of messages that can be processed in a single FETCH/SEARCH/STORE/COPY/MOVE (or their UID variants), APPEND or UID EXPUNGE command. This helps servers to control resource usage when performing various IMAP operations. This helps clients to know the message limit enforced by corresponding IMAP server and avoid issuing commands that would exceed such limit. <span>Status of This Memo</span> This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as &quot;work in progress.&quot; This Internet-Draft will expire on 30 January 2025. <span>Copyright Notice</span> Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust&#x27;s Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. <span>Melnikov, et al. Expires 30 January 2025 [Page 1]</span> <span>Internet-Draft IMAP MESSAGELIMIT July 2024</span> Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. <span>Table of Contents</span> 1. Introduction and Overview . . . . . . . . . . . . . . . . . . 3 2. Document Conventions . . . . . . . . . . . . . . . . . . . . 3 3. The MESSAGELIMIT extension . . . . . . . . . . . . . . . . . 3 3.1. Returning limits on the number of messages processed in a single SEARCH/FETCH/STORE/COPY/MOVE/APPEND/EXPUNGE command . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. UIDAFTER and UIDBEFORE SEARCH criteria . . . . . . . . . 7 3.3. Interaction with SORT and THREAD extensions . . . . . . . 8 3.4. Interaction with SEARCHRES extension and IMAP4rev2 . . . 8 4. Interoperability Considerations . . . . . . . . . . . . . . . 8 4.1. Effects of MESSAGELIMIT/SAVELIMIT extensions on non compliant clients . . . . . . . . . . . . . . . . . . . . 8 4.2. Maintaining Compatibility . . . . . . . . . . . . . . . . 9 5. Formal syntax . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7.1. Changes/additions to the IMAP4 capabilities registry . . 10 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 9.2. Informative References . . . . . . . . . . . . . . . . . 12 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors&#x27; Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 <span>Melnikov, et al. Expires 30 January 2025 [Page 2]</span> <span>Internet-Draft IMAP MESSAGELIMIT July 2024</span> 1. Introduction and Overview This document defines an extension to the Internet Message Access Protocol [RFC3501] for announcing a server limit on the number of messages that can be processed in a single FETCH/SEARCH/STORE/COPY/ MOVE (or their UID variants), APPEND or UID EXPUNGE command. This extension is compatible with both IMAP4rev1 [RFC3501] and IMAP4rev2 [RFC9051]. 2. Document Conventions In protocol examples, this document uses a prefix of &quot;C: &quot; to denote lines sent by the client to the server, and &quot;S: &quot; for lines sent by the server to the client. Lines prefixed with &quot;// &quot; are comments explaining the previous protocol line. These prefixes and comments are not part of the protocol. Lines without any of these prefixes are continuations of the previous line, and no line break is present in the protocol unless specifically mentioned. The key words &quot;MUST&quot;, &quot;MUST NOT&quot;, &quot;REQUIRED&quot;, &quot;SHALL&quot;, &quot;SHALL NOT&quot;, &quot;SHOULD&quot;, &quot;SHOULD NOT&quot;, &quot;RECOMMENDED&quot;, &quot;NOT RECOMMENDED&quot;, &quot;MAY&quot;, and &quot;OPTIONAL&quot; in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Other capitalised words are IMAP key words [RFC3501][RFC9051] or key words from this document. 3. The MESSAGELIMIT extension An IMAP server advertises support for the MESSAGELIMIT extension by including &quot;MESSAGELIMIT=&lt;limit&gt;&quot; capability in the CAPABILITY response/response code, where &quot;&lt;limit&gt;&quot; is a positive integer that conveys the maximum number of messages that can be processed in a single [UID] SEARCH/FETCH/STORE/COPY/MOVE, APPEND or UID EXPUNGE command. An IMAP server that only enforces message limit on [UID] COPY/APPEND commands would include the &quot;SAVELIMIT=&lt;limit&gt;&quot; capability (instead of the &quot;MESSAGELIMIT=&lt;limit&gt;&quot;) in the CAPABILITY response/response code. The limit advertised in the MESSAGELIMIT or SAVELIMIT capability SHOULD NOT be lower than 1000 messages. <span>Melnikov, et al. Expires 30 January 2025 [Page 3]</span> <span>Internet-Draft IMAP MESSAGELIMIT July 2024</span> 3.1. Returning limits on the number of messages processed in a single SEARCH/FETCH/STORE/COPY/MOVE/APPEND/EXPUNGE command If a server implementation doesn&#x27;t allow more than &lt;N&gt; messages to be operated on by a single COPY/UID COPY command, it MUST fail the command by returning a tagged NO response with the MESSAGELIMIT response code defined below. No messages are copied in this case. If a server implementation doesn&#x27;t allow more than &lt;N&gt; messages to be operated on by a single SEARCH/FETCH/STORE/MOVE (or their UID variants), APPEND or UID EXPUNGE command, it MUST return the MESSAGELIMIT response code defined below: MESSAGELIMIT The server doesn&#x27;t allow more than &lt;N&gt; messages to be operated on by a single SEARCH/FETCH/STORE/COPY/MOVE command (or their UID variants). The lowest processed UID is &lt;LastUID&gt;. The client needs to repeat the operation for remaining messages, if required. The server doesn&#x27;t allow more than &lt;N&gt; \Deleted messages to be operated on by a single UID EXPUNGE command. The lowest processed UID is &lt;LastUID&gt;. The client needs to repeat the operation for remaining messages, if required. Note that when the MESSAGELIMIT response code is returned, the server is REQUIRED to process messages from highest to lowest UIDs. Note that when the MESSAGELIMIT response code is similar to the LIMIT ([RFC9051]) response code, but it provides more details on the exact type of the limit and how to resume the command once the limit is exceeded. In the following example the &lt;N&gt; value is 1000 and the lowest processed UID &lt;LastUID&gt; is 23221. C: 03 FETCH 10000:14589 (UID FLAGS) S: * 14589 FETCH (FLAGS (\Seen) UID 25000) S: * 14588 FETCH (FLAGS (\Answered) UID 24998) S: ... further 997 fetch responses S: * 13590 FETCH (FLAGS () UID 23221) S: 03 OK [MESSAGELIMIT 1000 23221] FETCH completed with 1000 partial results In the following example the client searches for UNDELETED UIDs between 22000:25000. The total number of searched messages (note, NOT the number of matched messages) exceeds the server&#x27;s published 1000 messages limit. <span>Melnikov, et al. Expires 30 January 2025 [Page 4]</span> <span>Internet-Draft IMAP MESSAGELIMIT July 2024</span> C: 04 UID SEARCH UID 22000:25000 UNDELETED S: * SEARCH 25000 24998 (... UIDs ...) 23221 S: 04 OK [MESSAGELIMIT 1000 23221] SEARCH completed with 1000 partial results The following example demonstrates copy of messages with UIDs between 18000:21000. The total message count exceeds the server&#x27;s published 1000 messages limit. As COPY/UID COPY needs to atomic (as per [RFC3501]/[RFC9051]), no messages are copied. C: 05 UID COPY 18000:21000 &quot;Trash&quot; S: 05 NO [MESSAGELIMIT 1000 20001] Too many messages to copy, try a smaller subset The following example shows MOVE of messages with UIDs between 18000:21000. The total message count exceeds the server&#x27;s published 1000 messages limit. (Unlike COPY/UID COPY, MOVE/UID MOVE don&#x27;t need to be atomic.) The client that wants to move all messages in the range and observes a MESSAGELIMIT response code, can repeat the UID MOVE command with the same parameter. (For the MOVE command, the message set parameter need to be updated before repeating the command.) The client needs to keep doing this until the MESSAGELIMIT response is not returned (or until a tagged NO/BAD is returned). C: 06 UID MOVE 18000:21000 &quot;Archive/2021/2021-12&quot; S: * OK [COPYUID 1397597919 20001:21000 22363:23362] Some messages were not moved S: * 12336 EXPUNGE S: * 12335 EXPUNGE ... S: * 11337 EXPUNGE S: 06 OK [MESSAGELIMIT 1000 20001] MOVE completed for the last 1000 messages The following example shows update of flags for messages with UIDs between 18000:20000. The total number of existing messages in the UID range exceeds the server&#x27;s published 1000 messages limit. The client that wants to change flags for all messages in the range and observes a MESSAGELIMIT response code, can repeat the UID STORE command with the updated UID range that doesn&#x27;t include the UID returned in the MESSAGELIMIT response code. (For the STORE command, the message set parameter also need to be updated before repeating the command.) The client needs to keep doing this until the MESSAGELIMIT response is not returned (or until a tagged NO/BAD is returned). <span>Melnikov, et al. Expires 30 January 2025 [Page 5]</span> <span>Internet-Draft IMAP MESSAGELIMIT July 2024</span> C: 07 UID STORE 18000:20000 +FLAGS (\Seen) S: * 11215 FETCH (FLAGS (\Seen \Deleted) UID 20000) S: * 11214 FETCH (FLAGS (\Seen \Answered \Deleted) UID 19998) ... S: * 10216 FETCH (FLAGS (\Seen) UID 19578) S: 07 OK [MESSAGELIMIT 1000 19578] STORE completed for the last 1000 messages The following example shows removal of messages (using UID EXPUNGE) that have \Deleted flag set with UIDs between 11000:13000. The total message count of messages with \Deleted flag set exceeds the server&#x27;s published 1000 messages limit. The client that wants to remove all messages marked as \Deleted in the range and observes a MESSAGELIMIT response code, can repeat the UID EXPUNGE command with the same parameter. The client needs to keep doing this until the MESSAGELIMIT response is not returned (or until a tagged NO/BAD is returned). C: 08 UID EXPUNGE 11000:13000 S: * 4306 EXPUNGE S: * 4305 EXPUNGE ... S: * 3307 EXPUNGE S: 08 OK [MESSAGELIMIT 1000 11627] UID EXPUNGE completed for the last 1000 messages The following example shows removal of messages (using EXPUNGE) that have \Deleted flag set. Unlike UID EXPUNGE, the server MUST NOT impose any message limit when processing EXPUNGE. C: 09 EXPUNGE S: * 4306 EXPUNGE S: * 4305 EXPUNGE ... S: * 3307 EXPUNGE S: * 112 EXPUNGE S: 09 OK EXPUNGE completed Similarly, the server MUST NOT impose any message limit when processing a &quot;CLOSE&quot; or a &quot;STATUS UNSEEN&quot; command. The following example shows use of MESSAGELIMIT response code together with the PARTIAL [RFC9394] extension. The total message count (as specified by the PARTIAL range) exceeds the server&#x27;s published 1000 messages limit, so the server refuses to do any work in this case. <span>Melnikov, et al. Expires 30 January 2025 [Page 6]</span> <span>Internet-Draft IMAP MESSAGELIMIT July 2024</span> C: 10 UID FETCH 22000:25000 (UID FLAGS MODSEQ) (PARTIAL -1:-1500) S: 10 NO [MESSAGELIMIT 1000] FETCH exceeds the maximum 1000 message limit Without the PARTIAL parameter the above UID FETCH can look like this: C: 10 UID FETCH 22000:25000 (UID FLAGS MODSEQ) S: * 12367 FETCH (FLAGS (\Seen \Deleted) UID 23007) S: * 12366 FETCH (FLAGS (\Seen \Answered \Deleted) UID 23114) ... S: * 13366 FETCH (FLAGS (\Seen) UID 24598) S: 10 OK [MESSAGELIMIT 1000 23007] FETCH exceeds the maximum 1000 message limit Note that when the server needs to return both EXPUNGEISSUED ([RFC9051]) and MESSAGELIMIT response codes, the former MUST be returned in the tagged OK response, while the latter MUST be returned in an untagged NO response. The following example demonstrates that: C: 11 FETCH 10000:14589 (UID FLAGS) S: * 14589 FETCH (FLAGS (\Seen) UID 25000) S: * 14588 FETCH (FLAGS (\Answered) UID 24998) S: ... further 997 fetch responses S: * 13590 FETCH (FLAGS () UID 23221) S: * NO [MESSAGELIMIT 1000 23221] FETCH completed with 1000 partial results S: 11 OK [EXPUNGEISSUED] Some messages were also expunged When IMAP MULTIAPPEND [RFC3502] extension is also supported by the server, the message limit also applies to the APPEND command. As MULTIAPPEND APPEND needs to atomic (as per [RFC3502]), no messages are appended when the server MESSAGELIMIT is exceeded. 3.2. UIDAFTER and UIDBEFORE SEARCH criteria The MESSAGELIMIT extension also defines 2 extra SEARCH keys: UIDAFTER and UIDBEFORE, which make it easier to convert a single UID to a range of UIDs. &quot;UIDAFTER &lt;uid&gt;&quot; - Messages that have a UID greater than the specified UID. This is semantically the same as &quot;UID &lt;uid&gt;+1:*&quot;. &quot;UIDBEFORE &lt;uid&gt;&quot; - Messages that have a UID less than the specified UID. This is semantically the same as &quot;UID 1:&lt;uid&gt;-1&quot; (or if &lt;uid&gt; has the value 1, then the empty set). <span>Melnikov, et al. Expires 30 January 2025 [Page 7]</span> <span>Internet-Draft IMAP MESSAGELIMIT July 2024</span> These 2 SEARCH keys are particularly useful when the SEARCHRES [RFC5182] extension is also supported, but they can be used without it. For example, this allows a SEARCH that sets the &quot;$&quot; marker to be converted to a range of messages in a subsequent SEARCH, and both SEARCH requests can be pipelined. C: 12 UID SEARCH UIDAFTER 25000 UNDELETED S: * SEARCH 27800 27798 (... 250 UIDs ...) 25001 S: 12 OK SEARCH completed 3.3. Interaction with SORT and THREAD extensions Servers that advertise MESSAGELIMIT N will be unable to execute a THREAD [RFC5256] command in a mailbox with more than N messages. Servers that advertise MESSAGELIMIT N might be unable to execute a SORT [RFC5256] command in a mailbox with more than N messages, unless they maintain indices for different SORT orders they support. In absence of such indeces server implementors will need to decide whether their server advertises SORT or MESSAGELIMIT capability. 3.4. Interaction with SEARCHRES extension and IMAP4rev2 Servers that support both MESSAGELIMIT and SEARCHRES [RFC5182] extensions MUST truncate SEARCH SAVE result stored in the $ variable when the SEARCH command succeeds, but the MESSAGELIMIT response code is returned. For example, if the following SEARCH would have returned 1200 results in absence of MESSAGELIMIT, and the MESSAGELIMIT is 1000, only 1000 matching results will be saved in the $ variable: C: D0004 UID SEARCH RETURN (SAVE) SINCE 1-Jan-2004 NOT FROM &quot;Smith&quot; UID 22000:25000 UNDELETED S: D0004 OK [MESSAGELIMIT 1000 1179] SEARCH completed with 1000 partial results saved 4. Interoperability Considerations 4.1. Effects of MESSAGELIMIT/SAVELIMIT extensions on non compliant clients A server that advertises the MESSAGELIMIT=N capability would have the following effect on clients that don&#x27;t support this capability: Operations on a mailbox that has &lt;= N messages are not affected. In a mailbox with more than N messages: - An attempt to COPY/UID COPY more than N messages will always fail. <span>Melnikov, et al. Expires 30 January 2025 [Page 8]</span> <span>Internet-Draft IMAP MESSAGELIMIT July 2024</span> - EXPUNGE and CLOSE will always operate on the full mailbox, so they are not affected. - Other commands like FETCH, SEARCH and MOVE will be effectively restricted to the last N messages of the mailbox. In particular unextended SEARCHes intended for counting of messages with or without a particular set of flags would return incorrect counts. 4.2. Maintaining Compatibility It is important to understand that the above effects essentially abandon existing clients with respect to operation on large mailboxes. Suppose, for example, that a user is accessing a large and active mailing list via IMAP - the mailing list gets on the order of 1500 posts per week. When the user returns from a week-long vacation and catches up on the mailing list, the user鈥檚 client will be fetching information about 1500 messages. If the server has a MESSAGELIMIT of 1000, the client will only be able to download 1000 of most recent messages; the client will not understand why, will not be prepared to recover from the situation, and will act as if it is interacting with a broken server. In order to give clients time to implement this extension, servers should not be strict about applying the MESSAGELIMIT at first. One possible approach is to advertise a MESSAGELIMIT but not enforce it at all for a while. Clients that understand this extension will comply, reducing load on the server, but clients that do not understand the limit will continue to work in all situations. Another approach, perhaps phased in later, is to advertise one limit but to treat it as a soft limit and to begin enforcement at a higher, unadvertised hard limit. In the above example, perhaps the server might advertise 1000 but actually enforce a limit of 10,000. Again, clients that understand MESSAGELIMIT will comply with the limit of 1000, but other clients will still interoperate up to the higher threshold. Attempts to go beyond the advertised limit can be logged so that client understanding of MESSAGELIMIT can be tracked. If implementation and deployment of this extension becomes common, it may at some point be acceptable to strictly enforce the advertised limit and to accept that the remaining clients will, indeed, no longer work properly with mailboxes above that limit. <span>Melnikov, et al. Expires 30 January 2025 [Page 9]</span> <span>Internet-Draft IMAP MESSAGELIMIT July 2024</span> 5. Formal syntax The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation as specified in [ABNF]. Non-terminals referenced but not defined below are as defined by IMAP4 [RFC3501]. Except as noted otherwise, all alphabetic characters are case- insensitive. The use of upper or lower case characters to define token strings is for editorial clarity only. Implementations MUST accept these strings in a case-insensitive fashion. capability =/ &quot;MESSAGELIMIT=&quot; message-limit / &quot;SAVELIMIT=&quot; message-limit ;; &lt;capability&gt; from [RFC3501] message-limit = nz-number resp-text-code =/ &quot;MESSAGELIMIT&quot; SP message-limit [SP uniqueid] ;; No more than nz-number messages can be processed ;; by any command at a time. The last (lowest) processed ;; UID is uniqueid. ;; The last parameter is omitted, when not known. 6. Security Considerations This document defines an additional IMAP4 capability. As such, it does not change the underlying security considerations of [RFC3501] and IMAP4rev2 [RFC9051]. This document defines an optimization that can both reduce the amount of work performed by the server, as well at the amount of data returned to the client. Use of this extension is likely to cause the server and the client to use less memory than when the extension is not used, which can in turn help to protect from Denial-of-Service attacks. However, as this is going to be new code in both the client and the server, rigorous testing of such code is required in order to avoid introducing of new implementation bugs. 7. IANA Considerations 7.1. Changes/additions to the IMAP4 capabilities registry IMAP4 capabilities are registered by publishing a standards track or IESG approved Informational or Experimental RFC. The registry is currently located at: <span>Melnikov, et al. Expires 30 January 2025 [Page 10]</span> <span>Internet-Draft IMAP MESSAGELIMIT July 2024</span> https://www.iana.org/assignments/imap-capabilities/ IANA is requested to add registrations of &quot;MESSAGELIMIT=&quot; and &quot;SAVELIMIT=&quot; capabilities to this registry, both pointing to this document. 8. Acknowledgments This document was motivated by the Yahoo! team and their questions about best client practices for dealing with large mailboxes. Editor of this document would like to thank the following people who provided useful comments, contributed text or participated in discussions of this document: Timo Sirainen, Barry Leiba, Ken Murchison and Arnt Gulbrandsen. 9. References 9.1. Normative References [ABNF] Crocker, D., Ed. and P. Overell, Ed., &quot;Augmented BNF for Syntax Specifications: ABNF&quot;, RFC 5234, January 2008, &lt;https://www.rfc-editor.org/info/rfc5234&gt;. [RFC2119] Bradner, S., &quot;Key words for use in RFCs to Indicate Requirement Levels&quot;, BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, &lt;https://www.rfc-editor.org/info/rfc2119&gt;. [RFC3501] Crispin, M., &quot;INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1&quot;, RFC 3501, DOI 10.17487/RFC3501, March 2003, &lt;https://www.rfc-editor.org/info/rfc3501&gt;. [RFC3502] Crispin, M., &quot;Internet Message Access Protocol (IMAP) - MULTIAPPEND Extension&quot;, RFC 3502, DOI 10.17487/RFC3502, March 2003, &lt;https://www.rfc-editor.org/info/rfc3502&gt;. [RFC5182] Melnikov, A., &quot;IMAP Extension for Referencing the Last SEARCH Result&quot;, RFC 5182, DOI 10.17487/RFC5182, March 2008, &lt;https://www.rfc-editor.org/info/rfc5182&gt;. [RFC5256] Crispin, M. and K. Murchison, &quot;Internet Message Access Protocol - SORT and THREAD Extensions&quot;, RFC 5256, DOI 10.17487/RFC5256, June 2008, &lt;https://www.rfc-editor.org/info/rfc5256&gt;. <span>Melnikov, et al. Expires 30 January 2025 [Page 11]</span> <span>Internet-Draft IMAP MESSAGELIMIT July 2024</span> [RFC8174] Leiba, B., &quot;Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words&quot;, BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, &lt;https://www.rfc-editor.org/info/rfc8174&gt;. [RFC9051] Melnikov, A., Ed. and B. Leiba, Ed., &quot;Internet Message Access Protocol (IMAP) - Version 4rev2&quot;, RFC 9051, DOI 10.17487/RFC9051, August 2021, &lt;https://www.rfc-editor.org/info/rfc9051&gt;. 9.2. Informative References [RFC9394] Melnikov, A., Achuthan, A. P., Nagulakonda, V., and L. Alves, &quot;IMAP PARTIAL Extension for Paged SEARCH and FETCH&quot;, RFC 9394, DOI 10.17487/RFC9394, June 2023, &lt;https://www.rfc-editor.org/info/rfc9394&gt;. <span>Index</span> M M MESSAGELIMIT (response code) Section 3.1, Paragraph 2.2.1 <span>Authors&#x27; Addresses</span> Alexey Melnikov Isode Limited Email: alexey.melnikov@isode.com URI: https://www.isode.com Arun Prakash Achuthan Yahoo! Email: arunprakash@myyahoo.com Vikram Nagulakonda Yahoo! Email: nvikram_imap@yahoo.com Luis Alves Email: luis.alves@lafaspot.com <span>Melnikov, et al. Expires 30 January 2025 [Page 12]</span> </pre> </div> </div> </div> </div> </main> <footer class="col-md-12 col-sm-12 border-top mt-5 py-5 bg-light-subtle text-center position-sticky"> <a href="https://www.ietf.org/" class="p-3">IETF</a> <a href="https://www.ietf.org/iesg/" class="p-3">IESG</a> <a href="https://www.iab.org/" class="p-3">IAB</a> <a href="https://www.irtf.org/" class="p-3">IRTF</a> <a href="https://www.ietf.org/llc/" class="p-3 text-nowrap">IETF LLC</a> <a href="https://trustee.ietf.org/" class="p-3 text-nowrap">IETF Trust</a> <a href="https://www.rfc-editor.org/" class="p-3 text-nowrap">RFC Editor</a> <a href="https://www.iana.org/" class="p-3">IANA</a> <a href="https://www.ietf.org/privacy-statement/" class="p-3 text-nowrap">Privacy Statement</a> <div class="small text-body-secondary py-3"> <a class="mx-2" href="/release/about">About IETF Datatracker</a> <span class="mx-2"> <a href="https://github.com/ietf-tools/datatracker/releases/tag/12.28.2"> Version 12.28.2 (release - 7ecf23e) </a> </span> <a class="mx-2" href="https://status.ietf.org" target="_blank">System Status</a> <span class="mx-2 text-danger"> <i class="bi bi-bug"></i> Report a bug: <a class="text-reset" target="_blank" href="https://github.com/ietf-tools/datatracker/issues/new/choose">GitHub</a> <a class="text-reset" href="mailto:tools-help@ietf.org">Email</a> </span> </div> </footer> <script src="https://static.ietf.org/dt/12.28.2/ietf/js/d3.js"> </script> <script src="https://static.ietf.org/dt/12.28.2/ietf/js/document_timeline.js"> </script> <script src="https://static.ietf.org/dt/12.28.2/ietf/js/select2.js"></script> <script> $('#navbar-doc-search').on('select2:select', function (e) { window.location.href = e.params.data.url; }); </script> <script type="text/javascript"> var _paq = window._paq || []; _paq.push(['disableCookies']); _paq.push(['trackPageView']); _paq.push(['enableLinkTracking']); (function() { var u="//analytics.ietf.org/"; _paq.push(['setTrackerUrl', u+'matomo.php']); _paq.push(['setSiteId', 7]); var d=document, g=d.createElement('script'), s=d.getElementsByTagName('script')[0]; g.type='text/javascript'; g.async=true; g.defer=true; g.src=u+'matomo.js'; s.parentNode.insertBefore(g,s); })(); </script> <noscript><p><img src="//analytics.ietf.org/piwik.php?idsite=7" style="border:0;" alt="" /></p></noscript> <script>(function(){function c(){var b=a.contentDocument||a.contentWindow.document;if(b){var d=b.createElement('script');d.innerHTML="window.__CF$cv$params={r:'8e7af89e1b635e40',t:'MTczMjQ2Nzc5NC4wMDAwMDA='};var a=document.createElement('script');a.nonce='';a.src='/cdn-cgi/challenge-platform/scripts/jsd/main.js';document.getElementsByTagName('head')[0].appendChild(a);";b.getElementsByTagName('head')[0].appendChild(d)}}if(document.body){var a=document.createElement('iframe');a.height=1;a.width=1;a.style.position='absolute';a.style.top=0;a.style.left=0;a.style.border='none';a.style.visibility='hidden';document.body.appendChild(a);if('loading'!==document.readyState)c();else if(window.addEventListener)document.addEventListener('DOMContentLoaded',c);else{var e=document.onreadystatechange||function(){};document.onreadystatechange=function(b){e(b);'loading'!==document.readyState&&(document.onreadystatechange=e,c())}}}})();</script></body> </html>

Pages: 1 2 3 4 5 6 7 8 9 10