2025-09-19 This registry group was formerly known as "MAIL Parameters." RFC-ietf-emailcore-rfc5321bis-43, Sections 8.1.1, 2.2.2 Either Model 1 (IETF) or Model 2 (FCFS) as described in Sections 8.1.1.1 of RFC-ietf-emailcore-rfc5321bis-43. The Simple Mail Transfer Protocol specifies a set of commands or services and a general procedure for extending that set. The table below lists SMTP service extensions. Both message submission and mail transfer may use these extensions unless otherwise specified. The SMTP Extension names/keywords registered in this section are for general use. For those specific to Multicast email, see the registry for that protocol below. SEND Send to terminal None IETF MUST NOT The description of SEND was updated by and then its actual use was deprecated in IETF IETF SOML Send as mail or to terminal None IETF MUST NOT The description of SOML was updated by and then its actual use was deprecated in IETF IETF SAML Send as mail and to terminal None IETF MUST NOT The description of SAML was updated by and then its actual use was deprecated in IETF IETF VRFY VRFY command as specified in None None None IETF MUST NOT 0 Implementation support for VRFY is required in servers, but its listing in the EHLO response is optional. See Section 3.5.2 in for details on this subject. IETF IETF EXPN Expand the mailing list None IETF MUST NOT Command description updated by IETF IETF HELP Supply helpful information None IETF MUST NOT Command description updated by IETF IETF TURN Interchange the client and server roles None IETF MUST NOT The actual use of TURN was deprecated in IETF IETF 8BITMIME SMTP and Submit transport of 8bit MIME content None IETF SHOULD IETF IETF SIZE Message size declaration number IETF MAY For additional declarations or limits of this general type, see the LIMITS extension below and the SMTP Server Limits registry. IETF IETF VERB Verbose Eric Allman Not supplied Not supplied Not supplied Legacy Not supplied Not supplied Eric Allman Eric Allman ONEX One message transaction only Eric Allman Not supplied Not supplied Not supplied Legacy Not supplied Not supplied Eric Allman Eric Allman CHUNKING Chunking None IETF MAY IETF IETF BINARYMIME Binary MIME None IETF MAY IETF IETF CHECKPOINT Checkpoint/Restart None IETF MAY IETF IETF DELIVERBY Deliver By None IETF MAY IETF IETF PIPELINING Command Pipelining None IETF SHOULD IETF IETF DSN Delivery Status Notification None IETF SHOULD IETF IETF ETRN Extended Turn None IETF MUST NOT SMTP only. Not for use on Submit port 587. IETF IETF ENHANCEDSTATUSCODES Enhanced Status Codes None IETF SHOULD IETF IETF STARTTLS Start TLS None IETF MAY IETF IETF NO-SOLICITING Notification of no soliciting Soliciting-keywords IETF MAY IETF IETF MTRK Message Tracking IETF MAY IETF IETF SUBMITTER SMTP Responsible Submitter None IETF MUST NOT Deprecated by Moving RFC 4405, RFC 4406, RFC 4407 (Sender-ID) to Historic. IETF IETF ATRN Authenticated TURN None IETF MUST NOT SMTP only. Not for use on Submit port 587. IETF IETF AUTH Authentication SASL mechanism names IETF MUST IETF IETF BURL Remote Content Permitted URL prefixes IETF MUST NOT Submit only. Not for use with SMTP on port 25. IETF IETF FUTURERELEASE Future Message Release None IETF MUST NOT IETF IETF UTF8SMTP Internationalized email address None IETF MUST NOT Experimental; deprecated in . IETF IETF CONPERM Content Conversion Permission None IETF MAY IETF IETF CONNEG Content Conversion Negotiation None IETF MAY IETF IETF SMTPUTF8 Internationalized email address None IETF MUST NOT IETF IETF MT-PRIORITY Priority Message Handling Name of the Priority Assignment Policy (optional) IETF MUST NOT IETF IETF RRVS Require Recipient Valid Since None IETF MUST NOT IETF IETF REQUIRETLS Require TLS None IETF MUST NOT IETF IETF LIMITS Server limits None IETF MUST NOT See "SMTP Server Limits" registry. IETF IETF Registry closed These entries have been incorporated into the SMTP Service Extension registry's "EHLO Parameters" field. RFC-ietf-emailcore-rfc5321bis-43, Sections 8.1.3, 8.1.4 The Simple Mail Transfer Protocol and the Standard for Internet Message Formats specify that a set of "Received" lines will be prepended to the headers of electronic mail messages as they are transported through the Internet. These received line may optionally include either or both a "via" phrase and/or a "with" phrase. The legal values for the phrases are listed here. The via phrase is intended to indicate the link or physical medium over which the message was transferred. The with phrase is intended to indicate the protocol or logical process that was used to transfer the message. RFC Required UUCP Unix-to-Unix Copy Program TCP TCP RFC Required SMTP Simple Mail Transfer Protocol ESMTP SMTP with Service Extensions ESMTPA ESMTP with AUTH ESMTPS ESMTP with STARTTLS ESMTPSA ESMTP with both STARTTLS and AUTH LMTP Local Mail Transfer Protocol LMTPA LMTP with AUTH LMTPS LMTP with STARTTLS LMTPSA LMTP with both STARTTLS and AUTH MMS Multimedia Messaging Service UTF8SMTP ESMTP with SMTPUTF8 UTF8SMTPA ESMTP with SMTPUTF8 and AUTH UTF8SMTPS ESMTP with SMTPUTF8 and STARTTLS UTF8SMTPSA ESMTP with SMTPUTF8 and both STARTTLS and AUTH UTF8LMTP LMTP with SMTPUTF8 UTF8LMTPA LMTP with SMTPUTF8 and AUTH UTF8LMTPS LMTP with SMTPUTF8 and STARTTLS UTF8LMTPSA LMTP with SMTPUTF8 and both STARTTLS and AUTH IETF Review PRIORITY Records the value of the MT-PRIORITY parameter specified in the MAIL FROM command See Section 7 of RFC state Indicates entry into a special queue state state <state-name> tls Indicates the TLS cipher used tls-cipher = tls-cipher-name / tls-cipher-hex

tls-cipher-name = ALPHA *(ALPHA / DIGIT / "_")
; as registered in the IANA TLS Cipher Suite Registry

tls-cipher-hex = "0x" 4HEXDIG group Indicates the Diffie-Hellman group used with the TLS cipher (if applicable) dh-group = ALPHA *(ALPHA / DIGIT / "_" / "-")
; as registered in the IANA TLS Supported Groups Registry Standards Action Sometimes a host is not known to the domain name system and communication (and, in particular, communication to report and repair the error) is blocked. To bypass this barrier a special literal form of the address is allowed as an alternative to a domain name. For IPv4 addresses, this form uses four small decimal integers separated by dots and enclosed by brackets such as [123.255.37.2], which indicates an (IPv4) Internet Address in sequence-of-octets form. For IPv6 and other forms of addressing that might eventually be standardized, the form consists of a standardized "tag" that identifies the address syntax, a colon, and the address itself, in a format specified as part of the IPv6 standards . IPv6 Unassigned Specification Required MIXER Default policy RFC6710, Appendix B STANAG4406 RFC6710, Appendix A NSEP RFC6710, Appendix C First Come First Served auth Held for message authentication current content Held for message content analysis current convert Held for message content conversion current moderation Held for list moderation current normal Message is not being held other than to accommodate typical relaying handling current other Held for causes not covered by other registered state keywords current outbound Message placed in outbound queue current quarantine Held for operator action due to content analysis or local policy current timed Held to accommodate a specific requested delivery window current Specification Required Alexey Melnikov (primary), RFC Independent Submissions Editor (secondary) Extension names/keywords and status used with Multicast Email; see SMTP Service Extensions above for the list for more general use. SIZE Required 8BITMIME Required DSN Required MT-PRIORITY Required DELIVERBY Required BINARYMIME Required CHUNKING Special SMTP CHUNKING MUST be supported on the receiving SMTP side of an SMTP-to-MULE gateway and MAY be used on the sending side of a MULE-to-SMTP gateway. A MULE relay doesn't need to do anything special for this extension. ENHANCEDSTATUSCODES Special The ENHANCEDSTATUSCODES extension is supported by including relevant status codes in DSN reports. RRVS Supported SUBMITTER Supported Deprecated by Moving RFC 4405, RFC 4406, RFC 4407 (Sender-ID) to Historic. PIPELINING N/A STARTTLS N/A AUTH Special The AUTH parameter to the MAIL FROM command is "Supported", but the rest of the AUTH extension is not applicable to MULE. BURL N/A NO-SOLICITING N/A CHECKPOINT Disallowed CONNEG Disallowed Specification Required John Klensin, Murray Kucherawy (backup) MAILMAX %x31-39 0*5DIGIT ; "0" not allowed, six-digit maximum MAILMAX specifies the maximum number of transactions (MAIL FROM commands) the server will accept in a single session. The count includes all MAIL FROM commands, regardless of whether they succeed or fail. None See RFC9422, Section 6 RCPTMAX %x31-39 0*5DIGIT ; "0" not allowed, six-digit maximum RCPTMAX specifies the maximum number of RCPT TO commands the server will accept in a single transaction. It is not a limit on the actual number of recipients the message ends up being sent to; a single RCPT TO command may produce multiple recipients or, in the event of an error, none. None See RFC9422, Section 6 RCPTDOMAINMAX %x31-39 0*5DIGIT ; "0" not allowed, six-digit maximum RCPTDOMAINMAX specifies the maximum number of different domains that can appear in a recipient (RCPT TO) address within a single session. This limit is imposed by some servers that bind to a specific internal delivery mechanism on receipt of the first RCPT TO command. None See RFC9422, Section 6 Specification Required or IETF Review (see Note) Daniel Kahn Gillmor (primary), Bernie Hoeneisen (secondary) Adding an entry to this registry with an N in the "Recommended" column follows the registration policy of Specification Required. Adding an entry to this registry with a Y in the "Recommended" column or changing the "Recommended" column in an existing entry (from N to Y or vice versa) requires IETF Review. The Header Confidentiality Policy Name never appears on the wire. This registry merely tracks stable references to implementable descriptions of distinct policies. Any addition to this registry should be governed by guidance in Section 3.4.2 of . hcp_no_confidentiality No header confidentiality N RFC9788, Section 3.2.3 hcp_baseline Confidentiality for Informational Header Fields: Subject Header Field is obscured, Keywords and Comments are removed Y RFC9788, Section 3.2.1 hcp_shy Obscure Subject, remove Keywords and Comments, remove the time zone from Date, and remove display-names from From, To, and Cc N RFC9788, Section 3.2.2