Voice Profile for Internet Mail - version 2 (VPIMv2)
obsoletes
Extracted elements (29)
Multipart/Voice-Message is defined as semantically and syntactically identical to Multipart/Mixed so that systems not recognizing the sub-type can still process its contents safely, losing only the VPIM-specific identification.
Short numeric-only mailbox identifiers are preferred because voice messaging systems historically limit address entry to 16 or fewer numeric characters entered via telephone keypad. Alphanumeric local parts may be mapped to confusing local numbers or silently dropped by legacy systems, making the message unreplyable.
Some deployed implementations based on a common interpretation of the original VPIMv2 specification reject (rather than discard) messages with prohibited content within Multipart/Voice-Message, returning an NDN. Senders MUST NOT place prohibited content inside the Multipart/Voice-Message to maintain interoperability with these systems.
Text/Directory was profiled in the original VPIM v2 spec for transporting contact information but did not find widespread adoption and is no longer a feature. Conforming implementations SHOULD NOT send it, but MUST accept it for backward compatibility with earlier implementations.
VPIM's numeric+extension address format (e.g., +[email protected]) is not compatible with the addressing formats of RFCs 2303–2304. Convergence with general telephony addressing formats is expected as telephony services become more widespread on the Internet.
When ESMTP downgrading forces a relay hop to forward a VPIM message without DSN support, the downgrading system SHOULD continue delivery but MUST send an appropriate DSN to the originator noting that the DSN chain may be broken beyond that hop.
A globally unique Message-Id MUST be generated for each message sent from a VPIM-conforming implementation. When provided in the original message, the Message-Id MUST be used when sending an MDN.
A special mailbox named postmaster@domain MUST exist on all conforming systems for diagnostics. Conforming implementations MUST also reject any inbound message addressed to non-mail-user, returning an NDN with status code 5.1.1 ('Mailbox does not exist').
A VPIM-compliant implementation MUST be able to send and receive DSNs conforming to RFC 3462 (Multipart/Report) and RFC 3464 (Message/Delivery-Status). A non-delivery DSN MUST be sent whenever any form of non-delivery occurs unless the Return-Path is null.
All VPIM implementations that support facsimile MUST generate TIFF-F compatible content in the Image/TIFF subtype using application=faxbw encoding by default. The content-type parameter application=faxbw MUST be included in outbound fax messages.
An implementation conforming to this profile MUST send Audio/32KADPCM by default for voice content. Receivers MUST be able to accept and decode Audio/32KADPCM; if an implementation can handle only one voice body, multiple voice bodies SHOULD be concatenated and MUST NOT be discarded.
Conformant implementations MUST use Multipart/Voice-Message as the container for VPIM messages and MUST NOT create messages with prohibited contents (i.e., content types not profiled in section 4.4/4.5). In the spirit of liberal acceptance, a conforming system MAY accept and render prohibited content on receipt.
Content-Disposition MUST be present on every audio body part in a VPIM voice message, and audio contents MUST always carry disposition 'inline'. A filename value SHOULD be included when available.
If a message carries Sensitivity: Private, a conforming receiving system MUST prohibit the recipient from forwarding it. If the receiving system does not support privacy and sensitivity is Private, a negative DSN with status code 5.6.0 MUST be sent to the originator.
The MIME-Version: header MUST be present. Conforming systems SHOULD include the comment '(Voice 2.0)' to identify the profile version; however, this comment SHOULD NOT be used programmatically to identify a VPIM message — the presence of Multipart/Voice-Message content type SHOULD be used instead.
The originator's fully qualified domain address MUST be present in the From: header. Conforming systems SHOULD set the From: header value equal to the SMTP MAIL FROM address to avoid unanticipated behavior on voice mail platforms that cannot maintain separate attributes.
The sending system MUST report the time the message was sent in the Date: field, and the time zone MUST be present, represented as a four-digit offset (e.g., -0500). If no timestamp is available from the originating system, the gateway arrival time SHOULD be used.
The SMTP DSN extension MUST be supported by VPIM conforming implementations, including the NOTIFY parameter on the RCPT command. The SIZE extension MUST also be supported; ENHANCEDSTATUSCODES and PIPELINING SHOULD be supported.
VPIM addresses SHALL use the RFC 822 format based on the Domain Name System. The local part SHALL be a printable US-ASCII string containing the mailbox ID; short numeric local parts SHOULD be used because most voice mail networks rely on numeric mailbox identifiers compatible with the 10-digit telephone keypad.
When a reply is not possible (e.g., telephone-answering message), the special address non-mail-user@domain SHOULD be used as the originator address. A conforming implementation MUST NOT permit a reply to any message originating from non-mail-user.
When binary transport is not available, implementations MUST encode audio and/or facsimile data as Base64. Conforming implementations MUST recognize and decode Binary, 7bit, 8bit, Base64, and Quoted-Printable content-transfer encodings.
Users of voice messaging systems have a higher expectation of message privacy than standard Internet mail provides. This expectation SHOULD be preserved as much as possible; the specification does not preclude use of Internet object or channel security protocols (encryption, authentication, non-repudiation) to supplement VPIM messages.
A new 'voice' Content-Disposition parameter is defined with IANA-registered values: Voice-Message, Voice-Message-Notification, Originator-Spoken-Name, Recipient-Spoken-Name, and Spoken-Subject. Only one instance of each type SHOULD appear per message level; Recipient-Spoken-Name MUST NOT be used when multiple recipients are present.
Multipart/Voice-Message is a MIME multipart sub-type with semantics identical to Multipart/Mixed. It requires a boundary parameter and a version parameter ('2.0' for this specification). Future versions MUST maintain backwards compatibility with version 2.0.
The Sensitivity header field, borrowed from X.400, carries one of three values: Personal, Private, or Company-Confidential. Only 'Private' has VPIM-defined enforcement semantics; 'Personal' and 'Company-Confidential' MAY be ignored by receiving systems.
VPIM addresses may take four forms: (1) bare mailbox number, (2) mailbox number+extension, (3) +E.164 international number, and (4) +E.164 number+extension. The '+' prefix denotes a public telephone number per E.164; digit-only separators such as '-' may be ignored during parsing.
Appendix E registers two items with IANA: (1) the 'voice' Content-Disposition parameter with values Voice-Message, Voice-Message-Notification, Originator-Spoken-Name, Recipient-Spoken-Name, and Spoken-Subject; and (2) the Multipart/Voice-Message MIME media type with a required version parameter ('2.0').
Assigning an Internet mail address to a voice mailbox exposes it to unsolicited messages from unknown senders, which voice mail users perceive as a higher privacy breach than email spam. Many Internet mail systems block all messages from unknown sources to address this problem.
The actual sender of a VPIM message may not match the From: or Sender: headers or the SMTP MAIL FROM address. SMTP provides no inherent sender authentication; voice recognition of the audio content may offer independent identity confirmation in constrained environments.