Voice Profile for Internet Mail - version 2
obsoleted by
- rfc-3801 — Voice Profile for Internet Mail - version 2 (VPIMv2)
obsoletes
- rfc-1911 — Voice Profile for Internet Mail
Extracted elements (34)
Voice mail platforms typically limit mailbox IDs to 16 or fewer numeric digits, cannot display text, act as combined MTA/store/UA with no relay, and cannot store full RFC 822 header semantics. These constraints drove the VPIM profile's numeric addressing, mandatory ADPCM encoding, and simplified header handling.
VPIM makes as few restrictions and additions to existing Internet mail protocols as possible. This is motivated by the desire to leverage proven networking software for rapid development and to increase accessibility to digital messaging.
The MIME-Version comment '(Voice 2.0)' is informational only and SHOULD NOT be used to semantically identify a VPIM message; instead the presence of multipart/voice-message content SHOULD be used for identification.
The VPIM numeric address format (mailbox@domain, +E.164@domain) is designed for compatibility with the voice messaging industry and is explicitly NOT compatible with the addressing formats of RFCs 2303-2304.
When ESMTP DSN support is unavailable at a relay hop (SMTP downgrade), the downgrading system MUST send a delivery notification to the originator indicating the message left an ESMTP host and was forwarded unreliably via SMTP.
A conformant implementation MUST send Audio/32KADPCM by default for voice, and receivers MUST be able to accept and decode Audio/32KADPCM. This is the mandatory baseline voice encoding for interoperability.
A special mailbox named 'postmaster@domain' MUST exist on all systems for diagnostics. Implementations generating the non-mail-user@domain address MUST send a negative DSN (status 5.1.1) for any reply sent to that address.
A unique Message-ID MUST be generated for each message sent from a compliant implementation. Storage of the message-id on the receiving system is not required.
A VPIM system MUST add Received header fields when acting as a gateway and MUST NOT remove any existing Received fields when relaying messages to other MTAs or gateways.
Compliant implementations MUST implement the EHLO command and return the capabilities defined in this profile. The HELO command MUST be supported for backward compatibility but clients SHOULD NOT send it unless EHLO is not supported.
Compliant implementations MUST support the DSN ESMTP extension per RFC 1891, and MUST honor the NOTIFY parameter on RCPT TO to determine the conditions under which a delivery report is sent.
Compliant implementations MUST use the Multipart/Report construct for delivery status and message disposition notifications, and MUST recognize and decode it and its components in order to present the report to the user.
Compliant implementations SHOULD NOT implement the TURN command because SMTP lacks authentication, making TURN an opportunity to improperly fetch mail queued for another destination.
Compliant servers MUST provide the SIZE ESMTP extension to indicate the maximum message size they will accept. Clients SHOULD NOT send messages larger than the size the server advertises.
Conformant implementations MUST send the multipart/voice-message content type in a VPIM message and MUST recognize it whether it appears as a top-level content or beneath a multipart/mixed.
Each VPIM message SHOULD include a Text/Directory (vCard) content type, and when present it MUST contain at minimum the TEL, EMAIL, and VERSION (3.0) attributes of the message originator.
If a recipient header field list cannot be fully resolved (e.g., unknown DL expansion), the To header MUST be omitted to indicate that an accurate recipient list is not known.
If a Sensitivity header with value 'Personal' or 'Private' is present, a compliant system MUST prohibit the recipient from forwarding the message to any other user. If the receiving system cannot assure privacy, a negative DSN MUST be sent to the originator.
The Content-Disposition header MUST be present on each Audio/32KADPCM body part to allow parsable identification; the audio contents must always be of type 'inline'. A 'voice' disposition parameter with defined values (Voice-Message, Originator-Spoken-Name, Spoken-Subject, etc.) is used to distinguish audio content types.
The sending system MUST report the time the message was sent in the Date header. If the VPIM sender is relaying from a system without a timestamp, the time of arrival at the VPIM system SHOULD be used.
VPIM delivery status notification messages MUST be sent to the originator when any form of non-delivery occurs. Notifications MUST be contained in a multipart/report container and SHOULD include a spoken audio error message.
When binary transport is not available, implementations MUST encode audio and/or facsimile data as Base64. Detection and decoding of Quoted-Printable, 7bit, and 8bit encodings MUST also be supported to meet MIME requirements.
A Text/Directory content type containing a vCard (version 3.0) SHOULD be included in each VPIM message to convey originator identity. Required vCard attributes are TEL, EMAIL, and VERSION; SOUND (spoken name via content ID), N, ROLE, and REV are recommended.
The multipart/voice-message content type (defined in RFC 2423) is the mandatory container for a VPIM voice message. Its semantics are identical to multipart/mixed and may be interpreted as such by non-VPIM systems. It MUST contain only profiled media types: audio/*, image/*, message/rfc822, and text/directory.
Two conformance tiers are defined: transport conformance (store-and-forward with assured delivery and no information loss) and content conformance (generate and interpret VPIM message structures). End systems must be both; relay systems need only be transport conformant.
Two special reserved addresses are defined: postmaster@domain for diagnostics, and non-mail-user@domain to represent an unreachable originator (e.g., a telephone answering message) for which reply is not possible.
VPIM addresses use RFC 822 format with a numeric local part. Four forms are defined: plain mailbox number, mailbox+extension, +E.164 international number, and +E.164 number with PBX extension (e.g., +17035245550+[email protected]). The '+' prefix signals E.164 format.
Two IANA registrations are defined: (1) a 'VPIM' vCard EMAIL type to denote an email address that supports VPIM messages (Appendix 18.1); (2) a 'voice' Content-Disposition parameter with values Voice-Message, Voice-Message-Notification, Originator-Spoken-Name, Recipient-Spoken-Name, and Spoken-Subject (Appendix 18.2).
Assigning an Internet mail address to a voice mailbox exposes it to unsolicited messages. Voice mail users have higher privacy expectations than typical email users and may regard unsolicited mail as a security breach.
Implementation of the VRFY command may enable automated sweeps for valid mailbox addresses or guessing of recipient addresses, reducing mailbox privacy. Implementations may limit the number of VRFY queries per session to mitigate this risk.
SMTP provides no inherent authentication of message senders, so the From and Sender header fields and the MAIL FROM address may be spoofed. In voice mail contexts, recognition of the sender's voice may provide identity assurance independent of header fields.
Users of voice messaging systems expect a higher level of message privacy than is provided by Internet mail without security enhancements. This expectation SHOULD be preserved; the profile does not preclude use of Internet object or channel security protocols for encryption, authentication, or non-repudiation.
Audio/32KADPCM (G.726 32 kbit/s ADPCM) is the mandatory default voice encoding sub-type of audio/* used within multipart/voice-message. Body parts MUST carry a Content-Disposition: inline header with a 'voice' parameter identifying the audio role.
Facsimile content is encoded as image/tiff using the TIFF-F profile (RFC 2306). The content-type parameter 'application=faxbw' MUST be included in outbound messages. TIFF-F images MUST be encoded with exactly one image strip per facsimile page.