RFC 1911
Voice Profile for Internet Mail
RFC 1911: Voice Profile for Internet Mail 🎀
- Network Working Group 🌸
- Author: G. Vaudreuil, Octel Network Services 💅
- Category: Experimental 🧪
- Date: February 1996 📅
- Obsoletes / Updates: this title block doesn't list anything it obsoletes or updates ✨
Status of this Memo ✨
okay bestie, first things first: this memo defines an Experimental Protocol for the Internet community 🧪 It does NOT specify an Internet standard of any kind, so don't treat it like one 🙈 They're literally asking everyone for discussion and suggestions for improvement, and distribution of this memo is unlimited 🌈
1. Abstract 🦋
so there's this whole class of special-purpose computers that do voice messaging 📞 They usually plug into a telephone switch and handle call answering and voice messages. Traditionally, when a message had to go to a non-local machine, it got sent over analog networking protocols that run on DTMF signaling and analog voice playback 📼 But now that everyone wants networking, we need a standard high-quality digital protocol to connect these machines, and that's the whole point of this doc 💖
This profile is built on an earlier effort from the Audio Message Interchange Specification (AMIS) group, which tried to define a voice messaging protocol using X.400 technology 🧚 The goal here is to meet the user requirements from that earlier work while using the industry-standard ESMTP/MIME mail protocols that are already running inside corporate internets. The document calls this profile the voice profile 🫶
2. Scope and Design Goals 🎯
MIME is the Internet's multipurpose, multimedia messaging standard, and this document totally acknowledges what it can do 👑 It gives a way to exchange all kinds of messaging tech, including voice and facsimile 📠
This document is a profile of the TCP/IP multimedia messaging protocols for special-purpose voice processing platforms ☎️ These platforms have historically been special-purpose computers, and they often lack the stuff you'd normally expect on a regular Internet email-capable computer 🥺 The profile is meant to pin down the minimum common set of features and functionality for conformant systems ✨
The voice profile doesn't put limits on extra media types or protocol options 🌈 But conformant systems should not send messages with features beyond this profile unless someone has set up explicit per-destination configuration for those enhanced features 🙅♀️ That config info could live in a directory, though how you implement that is a local matter 🗂️
Here are the typical limitations of voice messaging platforms that were considered when making this baseline profile 🧠
- Text messages usually aren't received, and they often can't be displayed or viewed 📵 They can usually only be handled through advanced text-to-speech or text-to-fax features, and those aren't really in these machines yet 😭
- Voice mail machines usually act as both an integrated Message Transfer Agent and a User Agent 💅 The voice mail machine handles final delivery, and messages aren't relayed 🚫 RFC 822 header fields may have limited use with the simple messaging features that are currently deployed 🫠
- VM message stores generally can't preserve the full semantics of an Internet message 💀 So using a voice mail machine for general message forwarding and gatewaying isn't supported 🙈 Storing "Received" lines and
Message-IDmay be limited too 📭 - Nothing in this document stops a general purpose email gateway from providing these services 🌷 Still, you may see significant performance degradation if the email gateway doesn't support the ESMTP options this document recommends ⚡
- Internet-style mailing lists generally aren't supported 📭 Distribution lists are just local alias lists instead 📝
- There's usually no human operator 🤖 So error reports MUST be machine-parsable, which lets helpful responses reach users whose only access is a telephone 📞 (no cap, this part is kind of iconic)
- System user names are often limited to 16 or fewer numeric characters 🔢 Alpha characters aren't generally used for mailbox identification, since they're hard to enter from a telephone keypad 😩
The goal of this effort is to add as few restrictions and additions to the existing Internet mail protocols as possible, while still meeting the user requirements for interoperating with current voice messaging systems 💜 The motivation is to make digital messaging more accessible by letting people reuse proven networking software so development goes fast 🚀
This spec is meant for use on a TCP/IP network, but it's possible to use the SMTP protocol suite over other transport protocols too 🌊 The necessary protocol parameters for that are outside the scope of this document 🙃
This profile is meant to be robust enough for an environment like the global Internet, including installed base gateways that don't understand MIME 🌍 A messaging system is expected to be managed by a system administrator who can do TCP/IP network configuration 🧑💻 When you're using facsimile or multiple voice encodings, the system administrator is expected to keep a list of what each networked mail machine can do, so you don't send undeliverable messages because a feature isn't supported 📋 Configuring, implementing, and managing that capability listing is a local matter too 🔧
This spec is a profile of the relevant TCP/IP Internet protocols 🧩 Those technologies, plus the specs for Internet mail protocols, are defined in the Request for Comment (RFC) document series 📚 That series documents the standards as well as the lore of the TCP/IP protocol suite 🕰️ You should read this document alongside these RFCs: RFC 821 (Simple Mail Transfer Protocol); RFC 822 (Standard for the format of ARPA Internet Messages); RFC 1521 and RFC 1522 (Multipurpose Internet Mail Extensions); RFC 1651, RFC 1652, and RFC 1653 (SMTP Service Extensions, ESMTP); and RFC 1034 and RFC 1035 (Domain Name System) 🫶 If extra functionality is needed, it'll be defined in this document or in an appendix ✨
3. Protocol Restrictions 🚧
this protocol doesn't limit the number of recipients per message 🙌 Where possible, implementations should not restrict the number of recipients in a single message 💁♀️ Real talk though, no implementation supports unlimited recipients, and the supported number may be pretty low 😬 The catch is that ESMTP doesn't currently have a way to indicate how many recipients are supported 🤷♀️
This protocol doesn't limit the maximum message length either 📏 Implementors should understand that some machines won't be able to accept really long messages 📼 RFC 1425 ESMTP extensions define a mechanism for declaring the maximum message size a machine supports 💅
The message size given in the ESMTP SIZE command is in bytes, not minutes ⏱️ The number of bytes depends on the voice encoding format, and it must include the MIME wrapper overhead 🎁 If you need to know the length before sending, you can do an approximate translation into minutes, as long as you know the voice encoding 🧮
4. Voice Message Interexchange Format 💌
the voice message interchange format is a profile of the Internet Email Protocol Suite 🧁 It needs components from the Internet message format standard [RFC822], the Multipurpose Internet Message Extensions [MIME], the X.400 gateway specification [X.400], and the delivery report specifications [DRPT][STATUS] 🧩
4.1 Message Addressing Formats 📬
RFC 822 uses the domain name system 🌐 This naming system has two parts: the local part, which is used for username or mailbox identification, and the host part, which is used for global machine identification 🗺️
The local part of the address shall be an ASCII string that uniquely identifies a mailbox on a destination system 🔑 For voice messaging, the local part is a printable string holding the mailbox ID of the originator or recipient 📞 Administration of this space is expected to follow national or corporate private telephone numbering plans 🔢 Alpha characters and long mailbox identifiers are allowed, but most voice mail networks rely on numeric mailbox identifiers so they stay compatible with the limited 10 digit telephone keypad 🎹
For example, a compliant message may contain the address 2145551212@mycompany.com 💖 The example mailbox address is based on the North American Numbering Plan, but any other corporate numbering plan can be used too 🌏 The domain naming system should be transparent to the user 🫥 It's the voice mail machine's job to look up the fully-qualified domain name (FQDN) based on the address the user entered 🕵️♀️ How a dialed address maps to its final destination system is usually handled by implementation-specific means 🛠️
Special addresses are provided for compatibility with Internet mail conventions and to make testing easier 🧪 These addresses don't use numeric local addresses, which keeps them in line with current Internet practice and avoids clashing with existing numeric addressing plans 🙅♀️ Here are the special addresses:
Postmaster@domain 📮
By convention, a special mailbox named "postmaster" MUST exist on all systems 👑 This address is used for diagnostics, and the system manager should check it regularly 🩺 This mailbox is especially likely to receive text messages, which isn't normal on a voice processing platform 😳 How those messages get handled is an individual implementation choice 🧩
Loopback@domain 🔁
A special mailbox named "loopback" SHOULD be designated for loopback testing 🧪 If it's supported, every message sent to this mailbox MUST be returned back to the address listed in the From: address as a new message 📨 The originating address of the returned message MUST be "postmaster" to prevent mail loops 🌀
These two addresses are RESERVED, so they won't conflict with any internal addressing plan 🚨
4.2. Message Header Fields ✨
okay bestie, every internet message comes with a header block 📮 It's basically the info sheet: who sent it, who's getting it, when it went out, plus other stuff meant for the user to see 💅 Except for specialized gateway and mailing list cases, headers do not show delivery options for moving the message around 🚚
These header lines are allowed for voice messages 🎀
From
This is the originator's fully-qualified domain address, which is a mailbox address followed by the fully-qualified domain name 💌 The user listed here should show up in the voice message envelope as the originator 🦋
Systems that follow this profile SHOULD give the sender's text personal name in a quoted phrase if they have it ✨ To make it easy to store the text name in a local dial-by-name cache directory, the first and last name MUST be separable 🗂️ Text names in voice messages MUST be written in the form "last, first, mi." [822] 💖
Example:
From: "User, Joe S." <2145551212@mycompany.com>To
The To header holds the recipient's fully-qualified domain address 📬 There can be one or more To: fields in any message 🌈
Systems that follow this profile SHOULD give the recipient's text personal name, if it's known, in a quoted phrase 🎀 The name MUST be in the form "last, first, mi." [822] 🫶
Example:
To: "User, Sam S." <2145551213@mycompany.com>Cc
The CC header holds the fully-qualified domain addresses of additional recipients 👯 Lowkey, a lot of voice mail systems can't store or report the full list of recipients to the receiver 😭
Systems that follow this profile SHOULD give the recipient's text personal name, if it's known, in a quoted phrase 💜 The name MUST be in the form "last, first, mi." [822] ✨
Example:
To: "User, Sam S." <2145551213@mycompany.com>Systems that follow this profile may discard the CC list of incoming messages when necessary 🙈 Systems that follow this profile should give a complete list of recipients when possible 🌸
Date
The Date header holds the date, time, and time zone the originator sent the message 🕰️ Conforming implementations SHOULD be able to convert RFC 822 date and time stamps into local time 🧚
Example:
Date: Wed, 28 Jul 93 10:08:49 PSTThe sending system MUST report the time the message was sent [822] ⏰
Sender
The Sender header holds the actual address of the originator if an agent sends the message on behalf of the author listed in the From: field 🤖 Support for this field can't be assumed when talking to a voice system, so a conforming implementation SHOULD NOT generate it 🙅♀️
Not me being the one who has to explain this, but it matters: some voice mail machines might not be able to save this info, and if you throw away this information or the ESMTP MAIL FROM address, it gets really hard to send an error message to the right place 💀 [822]
Message-id
The Message-id header is a unique per-message identifier 🔑 A unique message-id MUST be generated for each message sent from a conforming implementation 🦄
The receiving system is not required to store the message-id 🫧 This identifier MAY be used for tracking, auditing, and returning read-receipt reports [822] 🍓
Example:
Message-id: <12345678@mycompany.com>Received
The Received header holds trace information that message transport agents (MTA) add to the beginning of an RFC 822 message 🛤️ It's the only header an MTA is allowed to add 👑 This info is useful for debugging when you're using an ASCII message reader or a header parsing tool 🔍
A conforming system MUST add Received headers when it's acting as a gateway, and it must not remove them 🚪 These headers MAY be ignored or deleted when the message arrives at the final destination [822] 🌷
MIME Version
The MIME-Version header says the message follows the MIME message format specification 📜 Systems that follow the voice messaging profile MUST include a comment with the words "(Voice 1.0)" [MIME] 🎤
Example:
MIME-Version: 1.0 (Voice 1.0)Content-Type
The Content-Type header declares what kind of content is inside the message 🎁 One of the allowed contents is multipart, which is a way to bundle several message components into one message 🧩 The allowed contents are specified in the next section of this document [MIME] 💅
Content-Transfer-Encoding
Internet mail was originally specified to carry only 7-bit US-ASCII text, so voice and fax data sometimes has to be encoded into a form that works in that environment 🔐 The content-transfer-encoding header describes that transformation if it's needed 🪄 Conformant implementations MUST recognize and decode the standard encodings, "Binary", "7bit, "8bit", "Base-64" and "Quoted-Printable" 🫶 The allowed content-transfer-encodings are specified in the next section of this document [MIME] ✨
Sensitivity
The sensitivity header, if it's there, shows the requested privacy level 🕵️♀️ The case-insensitive values "Personal" and "Private" are specified 🦋 If no privacy is requested, this field is left out 🙊
If a sensitivity header is in the message, a conformant system MUST stop the recipient from forwarding the message to any other user 🚫 If the receiving system doesn't support privacy and the sensitivity is "Personal" or "Private", the message MUST be sent back to the sender with an appropriate error code saying privacy couldn't be assured and the message wasn't delivered [X400] 😭🔥
Importance
This header shows the priority the receiving system should give the message 📈 The case-insensitive values "low", "normal" and "high" are specified 🌟 If no special importance is requested, the header may be left out and the value is assumed to be "normal" 🌼
Conformant implementations MAY use this header to show a message's importance, and they may order messages in a recipient's mailbox [X400] 🗂️
Subject
The subject field is often included by email systems, but it's not widely supported on voice mail platforms 🫠 This field MAY be generated by a conforming implementation, and a receiving system may discard it if it's present [822] 🌈
4.3 Message Content Types 🎀
okay so MIME is basically the super flexible body format that can carry a whole bunch of different body parts 💅 the basic protocol lives in [MIME]. it also has a way to encode binary data so it can ride over the 7-bit, text-only SMTP protocol 🫶 and that transport encoding is totally separate from the audio encoding used to make the binary object in the first place, so don't mix them up bestie 🙈
MIME defines two transport encodings that turn binary data into 7-bit stuff: Quoted-Printable (made for text-ish data) and Base-64 (for arbitrary binary). Base-64 is WAY more efficient for audio, ngl 🔥 but both work. when binary transport is available, you don't need any transport encoding at all, and the data can just be labeled Binary ✨
conformant implementations SHOULD send audio data in binary form whenever binary message transport is available 🦋 if binary transport isn't available, they MUST encode the message as Base-64 💖 and detecting and decoding Quoted-Printable, 7bit, and 8bit MUST be supported too, so you meet MIME requirements and keep talking to the widest range of devices possible 👑
the following content types are identified for use with this profile 🌈 each of these can be sent on its own in a message, or wrapped in a multipart message to send multi-segment messages.
Message/RFC822
MIME requires support of the Message/RFC822 message encapsulation body part 💅 the Internet uses this body part to forward complete messages inside a multipart/mixed message. processing it is trivial, it just decapsulates or encapsulates the message. conformant systems SHOULD NOT send this body part, but they MUST accept it if it's in conformance with basic MIME 🙈 how it's handled depends on the platform, and interpreting this content-type is left as an implementation decision [MIME].
Text/Plain
MIME requires support of the basic Text/Plain content type 💀 but it has zero applicability in the voice messaging environment, so conformant implementations MUST NOT send the Text/Plain content-type. they MUST accept Text/Plain messages anyway, though specific handling is up to the implementation 🫶 one option is to return the message to the sender with a media-unsupported error code [MIME].
Multipart/Mixed
MIME gives us the tools to enclose several body parts in a single message ✨ Multipart/Mixed MAY be used for sending multi-segment voice messages, which keeps the difference between an annotation and a forwarded message intact across the network 🦋 conformant systems MUST accept multipart/mixed body parts. systems MAY collapse such a multi-segment message into a single segment if multi-segment messages aren't supported on the receiving machine [MIME] 💅
Message/Notification
this MIME body part is used for sending machine-parsable delivery status notifications 🔥 conformant implementations must use the Message/Notification construct when returning messages or sending warnings. they must also recognize and decode the Message/Notification content type and present the reason for failure to the user [NOTIFY] 🙈
Multipart/Report
the Multipart/Report is used for enclosing a Message/Notification body part and any returned message content 🎀 it's basically the companion to Message/Notification. conformant implementations must use the Multipart/Report construct when returning messages or sending warnings, and they must recognize and decode the Multipart/Report content type [REPORT] 👑
Audio/32KADPCM
CCITT Recommendation G.721 [G721] describes the algorithm recommended for converting a 64 KB/s A-law or u-law PCM channel to and from a 32 KB/s channel 🧚 the conversion is applied to the PCM stream using an Adaptive Differential Pulse Code Modulation (ADPCM) transcoding technique. this algorithm will be registered with the IANA for MIME use under the name Audio/32KADPCM 💖
an implementation conformant to this profile MUST use Audio/32KADPCM by default 💅✨
Proprietary Voice Formats
proprietary voice encoding formats or other standard formats may be supported under this profile, as long as a unique identifier is registered with the IANA before use 🌸 these encodings should be registered as sub-types of Audio.
using any other encoding except Audio/32KADPCM reduces interoperability unless there's explicit manual system configuration 🙈 a conformant implementation MAY use any other encoding with explicit per-destination configuration 🦋
Multipart/Voice-Message
this new MIME multipart structure is the one that packages the sender's spoken name, a spoken subject, and the message itself 🎀 it has three segments: the spoken name, then the spoken subject, then the message 🫶 forwarded messages can be made by just nesting multipart content-types (this also works with Multipart/Mixed if there's no spoken name or spoken subject) ✨ this type is defined in an appendix to this document.
conforming implementations MUST send the Multipart/Voice-Message if a spoken name or spoken subject is available 💖 conforming implementations SHOULD recognize the Multipart/Voice-Message and separate out the spoken name or spoken subject 👑
5. Message Transport Protocol 🚀
messages get transported between voice mail machines using the Internet Extended Simple Mail Transfer Protocol (ESMTP) ✨ all the info needed for proper delivery is included in the ESMTP dialog. this info, including the sender and recipient addresses, is commonly called the message "envelope" 💌 it's the equivalent of the message control block in lots of analog voice networking protocols 🧚
ESMTP is a general-purpose messaging protocol, built both to send mail and to allow terminal console messaging 💅 Simple Mail Transport Protocol (SMTP) was originally made for exchanging US-ASCII 7-bit text messages. binary and 8-bit text messages have traditionally been moved by encoding them into a 7-bit text-like form 🙈 [ESMTP] was recently published and formalized an extension mechanism for SMTP, and later RFCs defined 8-bit text networking, binary networking, and extensions that let you declare message size for efficient transmission of big messages, like multi-minute voice mail 🔥
a command streaming extension for high performance message transmission has been defined [PIPE] 🦋 it cuts down on the number of round-trip packet exchanges and makes it possible to validate all recipient addresses in one operation 🫶 this extension is optional but recommended.
the following sections list the ESMTP commands, keywords, and parameters that are required and the ones that are optional 🎀
5.1 ESMTP Commands
HELO
base SMTP greeting and identification of the sender 💖 this command is not supposed to be sent by conforming systems unless the more-capable EHLO command isn't accepted. it's only included for compatibility with general SMTP implementations 🌸 conforming implementations MUST implement the HELO command for backward compatibility, but they SHOULD NOT send it unless EHLO isn't supported [SMTP] 🙈
MAIL FROM (REQUIRED)
originating mailbox 📬 this address contains the mailbox where errors should be sent. this address may not be the same as the message sender listed in the message header fields if the message came through a gateway or was sent to an Internet-style mailing list 🔥 conforming implementations MUST implement the extended MAIL FROM command [SMTP, ESMTP] 👑
RCPT TO
recipient's mailbox 💅 this field contains only the addresses the message should be delivered to for this transaction 💌 if multiple transport connections to multiple destination machines are needed for the same message, this list may not match the list of recipients in the message header 🧚 conforming implementations MUST implement the extended RCPT TO command [SMTP, ESMTP] ✨
DATA
initiates the transfer of message data 🫶 support for this command is required in the event that the remote system doesn't support the binary mode command BDAT 🙈 conforming implementations MUST implement the SMTP DATA command for backwards compatibility [SMTP] 🎀
TURN
requests a change of roles. the client that opened the connection offers to take on the role of server for any mail the remote machine may want to send 🌈
⚠️ because SMTP is not an authenticated protocol, the TURN command presents an opportunity to improperly fetch mail queued for another destination 😭 conforming implementations SHOULD NOT implement the TURN command [SMTP] 💀
QUIT
requests that the connection be closed 🦋 if it's accepted, the remote machine will reset and close the connection. conforming implementations MUST implement the QUIT command [SMTP] 👑
RSET
resets the connection to its initial state 🌸 conforming implementations MUST implement the RSET command [SMTP] 💖
VRFY
requests verification that this node can reach the listed recipient 🔍 even though RCPT TO includes this functionality too, VRFY lets you do the query without starting a mail transfer transaction 🧚 this command is useful for debugging and tracing problems 💅 conforming implementations MAY implement the VRFY command [SMTP] ✨
(ngl this part matters: implementing VRFY may make it easier to guess a recipient's mailbox or run automated sweeps for valid mailbox addresses, which could reduce privacy 😭 various implementation techniques can reduce the threat, such as limiting the number of queries per session [SMTP] 🔒)
EHLO
the enhanced mail greeting that lets a server announce support for extended messaging options 🚀 the extended messaging modes are discussed in a later section of this document 🎀 conformant implementations MUST implement the ESMTP command and return the capabilities indicated later in this memo [ESMTP] 👑
BDAT
the BDAT command is a higher efficiency alternative to the earlier DATA command, especially for voice 🦋 it provides native binary transport 🫶 voice messages are large binary objects that would otherwise get BASE-64 encoded, so BDAT gives a substantial improvement in transmission efficiency over DATA 🔥 conformant implementations SHOULD support binary transport using the BDAT command [BINARY] 💖
5.2 ESMTP Capabilities ✨
okay so this bit is about the ESMTP keywords that unlock extra features for voice messaging 🎀 think of them as the little perks a server flashes at you when you say hi 👋
PIPELINING
the "PIPELINING" keyword tells you the receiving SMTP can accept pipelined commands 🚀 pipelining makes the protocol way faster over wide area networks, which is literally the whole point 😭 Conformant implementations SHOULD support the command pipelining indicated by this parameter [PIPE] 💅
SIZE
the "SIZE" keyword is how the receiving SMTP says "this is the biggest message I'll take" 📦 Conformant implementations MUST provide the size capability and SHOULD honor any size limitations when sending [SIZE] 🫶
CHUNKING
the "CHUNKING" keyword says the receiver will support the high-performance binary transport mode 🔥 bestie, note that CHUNKING works with ANY message format and does NOT mean the message itself is binary encoded 🙈 Conformant implementations SHOULD support binary transport indicated by this capability [BINARY] 🌸
BINARYMIME
the "BINARYMIME" keyword means the receiver SMTP can accept binary encoded MIME messages 🦋 Conformant implementations should support binary transport indicated by this capability [BINARY] 🧚
NOTIFY
the "NOTIFY" keyword means the receiver SMTP will accept explicit delivery status notification requests 👑 Conformant implementations MUST support the delivery notification extensions in [DSN] 💜
5.3 ESMTP Parameters - MAIL FROM ✨
BINARYMIME
the current message is a binary encoded MIME message 🎀 Conformant implementations SHOULD support binary transport indicated by this parameter [BINARY] 💖
5.4 ESMTP Parameters - RCPT TO ✨
NOTIFY
the NOTIFY parameter says under which conditions a delivery report SHOULD be sent 📬 Conformant implementations must honor this request [DSN] 🌈
RET
the RET parameter says whether the content of the message should be returned 🍓 Conformant systems SHOULD honor a request for returned content [DSN] ⭐
6. Management Protocols 🧚
okay the Internet protocols give us a way to manage messaging systems, from the physical network all the way down to the message queues 🌸 SNMP should be supported on a compliant message machine 💅
6.1 Network Management
the digital interface to the VM and the TCP/IP protocols SHOULD be managed 🛠️ MIB II SHOULD be implemented to provide basic statistics and reporting of TCP and IP protocol performance [MIB II] 📊
6.2 Directory and Message Management
Conformant systems SHOULD provide for the management of message traffic and queue monitoring based on the Message and Directory MIB [MADMAN] 👀
7. References 📚
[MIME] Borenstein, N., and N. Freed, "Multipurpose Internet Mail Extensions", RFC 1521, Bellcore, Innosoft, September 1993.
[MSG822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, UDEL, August 1982.
[X400] Hardcastle-Kille, S., "Mapping between X.400(1988) / ISO 10021 and RFC 822", RFC 1327, UCL, May 1992.
[PIPE] Freed, N., and A. Cargille, "SMTP Service Extension for Command Pipelining", RFC 1854, October 1995.
[ESMTP] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker, "SMTP Service Extensions", RFC 1869, United Nations University, Innosoft International, Inc., Dover Beach Consulting, Inc., Network Management Associates, Inc., The Branch Office, November 1995.
[SIZE] Klensin, J, Freed, N., Moore, K, "SMTP Service Extensions for Message Size Declaration", RFC 1870, United Nations University, Innosoft International, Inc., November 1995.
[8BIT] Klensin, J., Freed, N., Rose, M., Stefferud, E., D. Crocker, "SMTP Service Extension for 8bit-MIMEtransport", RFC 1426, United Nations University, Innosoft International, Inc., Dover Beach Consulting, Inc., Network Management Associates, Inc., The Branch Office, February 1993.
[DNS1] Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, USC/Information Sciences Institute, November 1987.
[DNS2] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, USC/Information Sciences Institute, November 1987.
[SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, USC/Information Sciences Institute, August 1982.
[BINARY] Vaudreuil, G., "SMTP Service Extensions for Transmission of Large and Binary MIME Messages", RFC 1830, Octel Network Services, October 1995.
[NOTIFY] Moore, K., and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 1894, University of Tennessee, Octel Network Services, January 1996.
[REPORT] Vaudreuil, G., "The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages", RFC 1892, Octel Network Services, January 1996.
[DSN] Moore, K., "SMTP Service Extensions for Delivery Status Notifications", RFC 1891, University of Tennessee, January 1996.
[G721] CCITT Recommendation G.700-G.795 (1988), General Aspects of Digital Transmission Systems, Terminal Equipment. Blue Book.
[MADMAN] Freed, N., and S. Kille, "Mail Monitoring MIB", RFC 1566, January 1994.
[MIB II] Rose, M., "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", RFC 1158, May 1990.
8. Security Consideration 💀
bestie, this one is SERIOUS 🚨 please read it carefully
This document is a profile of existing Internet mail protocols. As such, it does not create any security issues not already existing in the profiled Internet mail protocols themselves.
9. Acknowledgments 🫶
The author would like to offer special thanks to Glenn Parsons/BNR for his extensive review, helpful suggestions, and extensive editing including the requirements matrix 💖
10. Author's Address 💌
Gregory M. Vaudreuil
Octel Network Services
17080 Dallas Parkway
Dallas, TX 75248-1905
Phone/Fax: +1-214-733-2722
EMail: Greg.Vaudreuil@Octel.Com11. Appendix - MIME/ESMTP Voice Profile Requirements Summary ✨
okay bestie, this is the cheat sheet 🎀 it's a giant table of every MIME and ESMTP voice profile feature, with little x's showing which column each one lands in. the columns are the big shared thing, so use the key below the table to decode them 💅
| | | | |S| |
| | | | |H| |F
| | | | |O|M|o
| | |S| |U|U|o
| | |H| |L|S|t
| |M|O| |D|T|n
| |U|U|M| | |o
| |S|L|A|N|N|t
| |T|D|Y|O|O|t
FEATURE |SECTION | | | |T|T|e
-------------------------------------------|----------|-|-|-|-|-|-
| | | | | | |
Message Addressing Formats: | | | | | | |
Use DNS host names |4.1 |x| | | | |
Use only numbers in mailbox IDs |4.1 | |x| | | |
Use alpha-numeric mailbox IDs |4.1 | | |x| | |
Support of postmaster@domain |4.1 | |x| | | |
Support of loopback@domain |4.1 | |x| | | |
| | | | | | |
Message Header Fields: | | | | | | |
Encoding outbound messages | | | | | | |
From |4.2 |x| | | | |
Addition of text personal name |4.2 | |x| | | |
To |4.2 |x| | | | |
Addition of text personal name |4.2 | |x| | | |
CC |4.2 | | |x| | |
Date |4.2 |x| | | | |
Sender |4.2 | | | |x| |
Message-id |4.2 | |x| | | |
Received |4.2 |x| | | | |
MIME Version: 1.0 (Voice 1.0) |4.2 |x| | | | |
Content-Type |4.2 |x| | | | |
Content-Transfer-Encoding |4.2 |x| | | | |
Sensitivity |4.2 | | |x| | |
Importance |4.2 | | |x| | |
Subject |4.2 | | |x| | |
Detection & Decoding inbound messages | | | | | | |
From |4.2 |x| | | | |
Utilize text personal name |4.2 | |x| | | |
To |4.2 |x| | | | |
Utilize text personal name |4.2 | | |x| | |
CC |4.2 | | |x| | |
Utilize text personal name |4.2 | | |x| | |
Date |4.2 |x| | | | |
Conversion of Date to local time |4.2 | |x| | | |
Sender |4.2 | | | |x| |
Message ID |4.2 |x| | | | |
Received |4.2 | |x| | | |
MIME Version: 1.0 (Voice 1.0) |4.2 |x| | | | |
Content Type |4.2 |x| | | | |
Content-Transfer-Encoding |4.2 |x| | | | |
Sensitivity |4.2 |x| | | | |1
Importance |4.2 | | |x| | |
Subject |4.2 | | |x| | |
| | | | | | |
Binary Content Encoding: | | | | | | |
Encoding outbound messages | | | | | | |
7BITMIME |4.3 | | | | |x|
8BITMIME |4.3 | | | | |x|
Quoted Printable |4.3 | | | | |x|
Base-64 |4.3 |x| | | | |2
Binary |4.3 |x| | | | |3
Detection & decoding inbound messages | | | | | | |
7BITMIME |4.3 |x| | | | |
8BITMIME |4.3 |x| | | | |
Quoted Printable |4.3 |x| | | | |
Base-64 |4.3 |x| | | | |
Binary |4.3 |x| | | | |
| | | | | | |
Message Content Types: | | | | | | |
Inclusion in outbound messages | | | | | | |
Message/RFC822 |4.3 | | | |x| |
Text/plain |4.3 | | | | |x|
Multipart/Mixed |4.3 | | |x| | |
Message/Notification |4.3 |x| | | | |
Multipart/Report |4.3 |x| | | | |
Audio/32KADPCM |4.3 |x| | | | |
Audio/* (proprietary encodings) |4.3 | | |x| | |
Multipart/Voice-Message |4.3 |X| | | | |
Detection & decoding in inbound messages | | | | | | |
Message/RFC822 |4.3 |x| | | | |
Text/plain |4.3 |x| | | | |
Multipart/Mixed |4.3 |x| | | | |
Message/Notification |4.3 |x| | | | |
Multipart/Report |4.3 |x| | | | |
Audio/32KADPCM |4.3 |x| | | | |
Audio/* (proprietary encodings) |4.3 | | |x| | |
Multipart/Voice-Message |4.3 |X| | | | |
| | | | | | |
Message Transport Protocol: | | | | | | |
ESMTP Commands | | | | | | |
HELO |5.1 |x| | | | |
MAIL FROM |5.1 |x| | | | |
RCPT TO |5.1 |x| | | | |
DATA |5.1 |x| | | | |
TURN |5.1 | | | | |x|
QUIT |5.1 |x| | | | |
RSET |5.1 |x| | | | |
VRFY |5.1 | | |x| | |
EHLO |5.1 |x| | | | |
BDAT |5.1 | |x| | | |3
ESMTP Keywords | | | | | | |
PIPELINING |5.2 | |x| | | |
SIZE |5.2 |x| | | | |
CHUNKING |5.2 | |x| | | |
BINARYMIME |5.2 | |x| | | |
NOTIFY |5.2 |x| | | | |
| | | | | | |
Management Protocols: | | | | | | |
Network management |6.1 | |x| | | |
Monitoring queues |6.2 | |x| | | |
-------------------------------------------|----------|-|-|-|-|-|-okay so the footnotes 🧚 these are the little extra rules hiding under the table:
- okay so if a sensitive message lands at a system that doesn't support sensitivity, it must be returned to the originator with an appropriate error notification 🙈
- this one's for when binary transport is not available 💀
- and this one's for when binary transport is available 🫶
12. Appendix - Example Voice Message
okay this is the full-send example 💅 one message with every single option switched on, going to two recipients. it carries the sender's spoken name and a short speech bit, and it's marked important and private 🔥
To: 2145551212@vm1.mycompany.com
To: "Parsons, Glenn, W." 2145551234@VM1.mycompany.com
From: "Vaudreuil, Greg" 2175552345@VM2.mycompany.com
Date: Mon, 26 Aug 93 10:20:20 CST
MIME-Version: 1.0 (Voice 1.0)
Content-type: Multipart/Voice-Message; Boundary = "MessageBoundary"
Content-Transfer-Encoding: 7bit
Message-ID: VM2.mycompany.com-123456789
Sensitivity: Private
Importance: High
--MessageBoundary
Content-type: Audio/32KADPCM
Content-Transfer-Encoding: Base-64
glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd
(This is a sample of the base-64 Spoken Name data) fgdhgd
jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gQ5tkjpokfgW
dlkgpokpeowrit09==
--MessageBoundary
Content-type: Audio/32KADPCM
Content-Transfer-Encoding: Base-64
glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd
(This is a sample of the base-64 Spoken Subject data) fgdhgd
jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gQ5tkjpokfgW
dlkgpokpeowrit09==
--MessageBoundary
Content-type: Audio/32KADPCM
Content-Transfer-Encoding: Base-64
glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd
(This is a sample of the base-64 message data) fgdhgdfwgd
jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gQ5tkjpokfgW
dlkgpokpeowrit09==
--MessageBoundary--13. Appendix - Audio/32KADPCM Content Type
here's the Audio/32KADPCM content type spec 🦋 the basics come first:
Mime type name: Audio
Mime Sub-Type name: 32KADPCM
Required Parameters: None
Optional Parameters: None
Encoding Considerations: Any encoding necessary for transport may be
used.the vibe of the codec is this: CCITT Recommendation G.721 [G721] is the algorithm they recommend for turning a 64 KB/s A-law or u-law PCM channel into a 32 KB/s channel and back again 🌈 the conversion runs on the PCM stream using Adaptive Differential Pulse Code Modulation (ADPCM) transcoding, so that's the whole trick ✨
and the final bits, bestie: no header information shall be included before the audio data 🙈 and when this subtype shows up, a sample rate of 8000 Hz and a single channel get assumed 💜
14. Appendix - Multipart/Voice-Message ✨
okay so this is the appendix for the Multipart/Voice-Message type, and it's giving main character energy 🎀 here's the header block, copied exactly:
Mime type name: Multipart
Mime Sub-Type name: Voice-Message
Required Parameters: Boundary
Optional Parameters: None
Encoding Considerations: Binary of 7 bit are sufficient. Base-64
and Quoted-Printable are prohibited on multipart content-types.bestie, the encoding part is the one to watch 👀 Binary or 7-bit is fine, but Base-64 and Quoted-Printable are prohibited on multipart content types 🙅♀️
The syntax of a Multipart/Voice-Message is identical to Multipart/Mixed 💜 So the structure is the same, the only difference is what the parts are for. This one has three body parts 🦋 The first is an audio segment with the spoken name of the sender, the second is an audio segment with a spoken subject, and the third is the voice message itself. And forwarding is so easy, you just nest multipart content types inside each other 🔁 Literally a chain of voicemails 💅
The spoken name segment is the sender's name, said in their own voice 🗣️✨ It is limited to 12 seconds ⏱️ If there's no spoken name available, the segment still has to be there, it's just allowed to be empty 🫶
The spoken subject segment works the same way. It's the subject of the message, said in the sender's voice 🎧 This one can run up to 20 seconds. If there's no spoken subject, it still has to show up, but it can be empty 🌸
The voice message body part is pretty flexible 🌈 It can hold any arbitrary content, even a multipart/mixed collection of body parts. It will usually just be an audio segment though 🎙️
The default handling is the iconic part 👑 A Multipart/Voice-Message is voiced in this order: first the spoken-name segment, then the spoken-subject, and only then the rest of the message gets displayed or voiced. So you hear who it's from and what it's about before the actual message hits 💖
📦 where this page comes from
- ietf: rfc1911 1996-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms