Voice Message Routing Service
Two ways to reach a voice mailbox when all you know is a telephone number.
Vaudreuil, G., "Voice Message Routing Service", RFC 4238, DOI 10.17487/RFC4238, October 2005, <https://www.rfc-editor.org/info/rfc4238>.
@misc{rfc4238,
series = {Request for Comments},
number = 4238,
howpublished = {RFC 4238},
publisher = {RFC Editor},
doi = {10.17487/RFC4238},
url = {https://www.rfc-editor.org/info/rfc4238},
author = {G. Vaudreuil},
title = {{Voice Message Routing Service}},
pagetotal = 10,
year = 2005,
month = oct,
} RFC text
Contents
Network Working Group G. Vaudreuil
Request for Comments: 4238 Lucent Technologies
Category: Standards Track October 2005
Voice Message Routing Service
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
Voice messaging is traditionally addressed using telephone number
addressing. This document describes two techniques for routing voice
messages based on a telephone number. The complete service uses the
Voice Profile for Internet Mail (VPIM) Directory service to lookup a
VPIM email address with a telephone number and confirm that the
address is both valid and associated with the intended recipient.
However, this service will take time to become widely deployed in the
near term. This document also describes a basic send-and-pray
service that routes and delivers messages using only the ENUM
telephone number resolution service and the existing DNS mail routing
facilities.
Table of Contents
1. Design Goals ....................................................2
2. The Complete Service ............................................3
2.1. Specification of Service "E2U+VPIM:LDAP" ...................3
2.2. VPIM Directory Discovery ...................................4
2.3. Address Query ..............................................4
3. The Basic Service ...............................................4
3.1. Specification of Service "E2U+VPIM:Mailto:" ................5
3.2. Address Construction .......................................6
3.3. Interdomain Message Routing ................................6
3.4. Intradomain Message Routing ................................6
3.4.1. Directory-Enabled Routing ...........................6
3.4.2. Service-based Mail Routing ..........................7
4. Security Considerations .........................................7
4.1. Unsolicited Bulk Email .....................................7
4.2. DNS-based Attacks ..........................................7
5. IANA Considerations .............................................8
6. References ......................................................8
6.1. Normative References .......................................8
6.2. Informative References .....................................8
1. Design Goals
This profile is intended to provide a range of functional
capabilities for message routing based on one of two mechanisms. The
most complete service should use the ENUM address resolution service
to determine the VPIM directory, and then use LDAP to retrieve the
VPIM-specific email address that will be used for message routing.
The more basic send-and-pray message service uses only the ENUM
service and MX records to route the message to the intended
recipient's domain. The intelligence to further route the message to
the intended recipient is placed within the message routing system of
the recipient's domain.
The basic mechanism may be used even when there is a VPIM directory
service available. The basic service is useful when LDAP queries are
not available, such as may be the case for disconnected mobile
terminals or because of firewall or information security policies.
The basic mechanism should facilitate the routing of VPIM messages to
a suitable internal destination with a minimum of configuration. It
is an important goal to avoid any content-processing to determine the
nature of the message and its internal destination. At a minimum, it
should be possible to establish a simple mail forwarding rule that
sends all inbound VPIM messages to a designated system, while
facilitating the routing of FAX, SMS, or other telephone-addressed
messages to other potentially different systems.
It is a goal that the mechanisms outlined in this document be
extensible for all store-and-forward, telephone-number addressed
messaging services.
It is a goal that the VPIM directory discovery and VPIM directory
query steps occur within the timing constraints for user interfaces
in PSTN networks. 95% of the time, that constraint can be a two-
second response.
2. The Complete Service
For the complete VPIM message routing service, the sending client
SHOULD query the VPIM directory for the VPIM-specific email address.
The client SHOULD use the ENUM service to retrieve the identity of
the VPIM Directory to query. The client should then query that
server for the email address and any additional attributes desired.
2.1. Specification of Service "E2U+VPIM:LDAP"
* Service Name: E.164 to VPIM LDAP URL
* URI Type: "LDAP:"
* Type: VPIM
* Subtype: LDAP
* Functional Specification: See sections 3.2 through 3.3
* Intended Usage: COMMON
* Author: Greg Vaudreuil (gregv@ieee.org)
* Security Considerations:
o Malicious Redirection
One of the fundamental dangers related to any service such as
this is that a malicious entry in a resolver's database will
cause clients to resolve the E.164 into the wrong LDAP URL.
The possible intent may be to cause the client to connect to a
rogue LDAP server and retrieve (or fail to retrieve) a resource
containing fraudulent or damaging information.
o Denial of Service
By removing the URL to which the E.164 maps, a malicious
intruder may remove the client's ability to access the LDAP
directory server.
2.2. VPIM Directory Discovery
The VPIM directory server is found by using the ENUM protocol and
querying for the VPIMDIR service associated with the telephone number
of the recipient.
The DNS query name is created as described by [ENUM]. The telephone
number used for the directory location MAY contain additional sub-
address information as additional digits.
Example:
Query: 2.1.2.1.5.5.5.3.1.6.1.e164.arpa
Responses:
IN NAPTR 10 10 "U" "E2U+VPIM:LDAP" \
"!^.*$!ldap://vdir1.Zcorp.com/telephoneNumber=\1!" .
IN NAPTR 10 20 "U" " E2U+VPIM:LDAP" \
"!^.*$!ldap://vdir2.Zcorp.com/telephoneNumber=\1!" .
It is recommended that VPIMDIR servers be deployed in a redundant
configuration. NAPTR weight fields provide the ability to give two
records indicating the same service and preference a different
weight. The same weight can be specified for random distribution
between the two servers. See [NAPTR-1, NAPTR-2, NAPTR-3, NAPTR-4]
2.3. Address Query
Once the VPIM directory is discovered, the client SHOULD issue an
LDAP query for the vPIMrFC822Mailbox, that is, the address that
SHOULD be used as the value for both the RFC 822 To: field and the
SMTP RCPT command. See [VPIMDIR].
3. The Basic Service
The basic service relies upon NAPTR rewrite rules to mechanically
construct a valid VPIM-specific email address. In the recipient's
domain, the constructed address may be further routed using
intradomain mail routing techniques.
To facilitate a full range of intradomain routing options, the
constructed email address indicates that the message is a VPIM
message. For ease of processing in the recipient's intradomain mail
routing system, the indication that the message is a VPIM message
SHOULD be in the domain name portion.
Note that there is no assurance the constructed address is valid, nor
that the constructed address corresponds to the intended recipient.
Because no capabilities information is provided about the recipient,
messages sent with this mechanism SHOULD be sent using only the media
and content types of the VPIM V2 profile.
3.1. Specification of Service "E2U+VPIM:Mailto:"
* Service Name: E.164 to VPIM MailTo: URL
* URI Type: "Mailto:"
* Type: VPIM
* Subtype: MAILTO
* Functional Specification: See sections 4.2 through 4.4
* Intended Usage: COMMON
* Author: Greg Vaudreuil (gregv@ieee.org)
* Error Conditions:
o E.164 number not in the numbering plan
o E.164 number in the numbering plan, but no URLs exist for that
number
o E2U+VPIM:Mailto Service unavailable
* Security Considerations:
o Malicious Redirection
One of the fundamental dangers related to any service such as
this is that a malicious entry in a resolver's database will
cause clients to resolve the E.164 into the wrong email URL.
The possible intent may be to cause the client to send the
information to an incorrect destination.
o Denial of Service
By removing the URL to which the E.164 maps, a malicious
intruder may remove the client's ability to access the
resource.
o Unsolicited Bulk Email
The exposure of email addresses through the ENUM service
provides a bulk mailer access to large numbers of email
addresses where only the telephone number was previously known.
3.2. Address Construction
Construct a VPIM email address using the address rewrite rules of the
NAPTR records associated with the VPIM service.
3.3. Interdomain Message Routing
The interdomain routing of a constructed VPIM address is mechanically
indistinguishable from existing email routing. No changes to the
infrastructure are required. The sending system consults the Domain
Name System for an MX record corresponding to the domain name and
forwards the message to the indicated system.
3.4. Intradomain Message Routing
Within the recipient's domain, the message may be further routed to
the appropriate messaging system. Two general mechanisms may be used
to further route the message to the intended system within a network.
Note: This section is strictly informational. The mechanisms for
intradomain routing are an internal matter for the domain and do
not affect the protocol. It is only necessary that the addresses
created by the NAPTR rewrite rules have meaning to the domain
advertising them. However, a convention for the creation and use
of such addresses may be useful.
3.4.1. Directory-Enabled Routing
Various proprietary directory mechanisms provide a means for an
inbound mail router of the recipient's domain to send a message to
the appropriate internal mail host. In many cases, the local part of
the address is used to query for an internal mail address. That
internal mail address is substituted for the SMTP RCPT address and
used to deliver the message to the recipient mailbox. Note that the
mailbox does not need to have any knowledge of the mechanically-
constructed telephone number-based address.
Example address: +12145551212@sp.net
3.4.2. Service-based Mail Routing
Alternately, a mail gateway may simply send all voice messages into a
separate messaging system. That system may be a single voice
messaging server or a service-specific gateway into a larger
telephone number-based voice-messaging network.
Such a mail gateway may be provisioned with a simple rule or small
set of rules to forward all messages of a given service type to a
pre-defined server. This rule would check for the service name
"VPIM" as a prefix to the constructed domain name to reroute
messages.
Example address: +12145551212@VPIM.sp.net
4. Security Considerations
There is little information disclosed to the sender of the message
that is not already disclosed using standard email protocols. The
ability to use this protocol to probe for valid addresses is
identical to the sending of test messages and waiting for a non-
delivery notification in return.
4.1. Unsolicited Bulk Email
However, the use of ENUM records to create routable email addresses
from telephone numbers provides bulk-emailers the capabilities to
send email to a large set of recipients where only the telephone
number is known or where telephone numbers are guessed.
4.2. DNS-based Attacks
Both the complete and basic services rely upon the DNS to provide the
information necessary to validate a recipient or send a message. The
message sender is a casual, unauthenticated use of the indicated
servers, and relies upon the DNS for accurate information. If the
DNS is compromised, an attacker can redirect messages by providing a
malicious email address or indicating a rogue directory with
malicious LDAP URL's. Use of DNS Security protocols [DNSSEC]
substantially reduces the risk of a domain being hijacked. If the
E.164 zone is secured with DNSSEC, then the attack is precluded if
the client can trust the key used to sign the zone. DNS security
does not protect against the LDAP service being independently
compromised. Further discussion on the risk to this LDAP service is
provided in [VPIMDIR].
5. IANA Considerations
This specification registers the E2U+VPIM and E2U+Voice services
according to the specifications and guidelines in RFC 3761 [ENUM] and
the definitions in this document.
6. References
6.1. Normative References
[ENUM] Faltstrom, P. and M. Mealling, "The E.164 to Uniform
Resource Identifiers (URI) Dynamic Delegation Discovery
System (DDDS) Application (ENUM)", RFC 3761, April 2004.
[NAPTR-1] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
Part One: The Comprehensive DDDS", RFC 3401, October 2002.
[NAPTR-2] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
Part Two: The Algorithm", RFC 3402, October 2002.
[NAPTR-3] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
Part Three: The Domain Name System (DNS) Database", RFC
3403, October 2002.
[NAPTR-4] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
Part Four: The Uniform Resource Identifiers (URI)", RFC
3404, October 2002.
[VPIMDIR] Vaudreuil, G., "Voice Messaging Directory Service", RFC
4237, October 2005.
6.2. Informative References
[VPIMV2] Vaudreuil, G. and G. Parsons, "Voice Profile for Internet
Mail - version 2 (VPIMv2)", RFC 3801, June 2004.
[DNSSEC] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", RFC
4033, March 2005.
Author's Address
Please send comments on this document to the VPIM working group
mailing list <vpim@ietf.org>.
Gregory M. Vaudreuil
Lucent Technologies
9489 Bartgis Ct
Frederick, MD 21702
EMail: GregV@ieee.org
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
ISO Plain Language
On this page
§1Design Goals
RFC 4238 profiles two mechanisms for routing messages that are addressed by a telephone number. The most complete service uses the ENUM address resolution service to determine the VPIM directory, then uses LDAP to retrieve the VPIM-specific email address that will be used for routing. The more basic send-and-pray service uses only ENUM and MX records to route the message to the recipient's domain, leaving the intelligence to route it further inside that domain to the domain's own message routing system.
The basic mechanism may be used even when a VPIM directory service is available. It is useful when LDAP queries are not available, such as with disconnected mobile terminals or because of firewall or information security policies. The design aims to avoid any content processing to determine the nature of the message and its internal destination. At a minimum, it should be possible to establish a simple mail forwarding rule that sends all inbound VPIM messages to a designated system, while routing FAX, SMS, or other telephone-addressed messages to other, potentially different, systems.
The mechanisms are meant to be extensible to all store-and-forward, telephone-number addressed messaging services. A timing goal also applies: the VPIM directory discovery and VPIM directory query steps should occur within the timing constraints for user interfaces in PSTN networks, where the constraint can be a two-second response 95% of the time.
The document sets out two ways to route a voice message from a phone number. The careful way looks up an email address in a directory. The simple way builds an address by rule and lets the recipient's mail system sort it out. Both must be fast: the RFC sets a goal of a two-second answer 95% of the time.
| Service | URI type | How the address is found | Is the address confirmed |
|---|---|---|---|
| E2U+VPIM:LDAP | LDAP: | ENUM finds the directory, LDAP returns the address | Yes, by the directory |
| E2U+VPIM:Mailto: | Mailto: | NAPTR rewrite rules build it from the number | No |
§2The Complete Service
For the complete VPIM message routing service, the sending client SHOULD query the VPIM directory for the VPIM-specific email address. The client SHOULD use the ENUM service to retrieve the identity of the VPIM directory to query, and then query that server for the email address and any additional attributes desired.
The service is registered as E2U+VPIM:LDAP, with URI type LDAP:, type VPIM, subtype LDAP and intended usage COMMON. Because the address comes from a directory, this service both finds the mailbox and confirms that the address is valid and associated with the intended recipient. The RFC notes that this service will take time to become widely deployed in the near term.
The complete service makes two lookups before the message is sent. First the sender asks the DNS which directory holds voice messaging details for that number. Then it asks that directory for the email address of the person. Because the address comes from a directory, the sender learns that it is valid and belongs to the intended recipient.
- ENUM query for the VPIMDIR serviceThe query name is built as described in RFC 3761.
- NAPTR answer holding an LDAP URLThe name of a directory server.
- LDAP query for vPIMrFC822Mailbox
- The VPIM email addressUsed in the To: field and in the SMTP RCPT command.
§2.2VPIM Directory Discovery
The VPIM directory server is found by using the ENUM protocol and querying for the VPIMDIR service associated with the telephone number of the recipient. The DNS query name is created as described by RFC 3761. The telephone number used for the directory location MAY contain additional sub-address information as additional digits.
The answer is one or more NAPTR records holding LDAP URLs. It is recommended that VPIMDIR servers be deployed in a redundant configuration. The NAPTR weight fields provide the ability to give two records indicating the same service and preference a different weight, and the same weight can be specified for random distribution between the two servers.
The sender looks the number up in the DNS using the ENUM service defined in RFC 3761. The answer is a NAPTR record that names a directory server. A number may carry extra digits for a sub-address. The RFC recommends running more than one directory server and using the NAPTR weight field to decide how requests are shared.
Query: 2.1.2.1.5.5.5.3.1.6.1.e164.arpa
Responses:
IN NAPTR 10 10 "U" "E2U+VPIM:LDAP" \
"!^.*$!ldap://vdir1.Zcorp.com/telephoneNumber=\1!" .§2.3The Address Query
Once the VPIM directory is discovered, the client SHOULD issue an LDAP query for vPIMrFC822Mailbox, that is, the address that SHOULD be used as the value for both the RFC 822 To: field and the SMTP RCPT command, as described in RFC 4237.
This lookup is what makes the service complete. The address is not assembled from a rule; the directory states it, so the sender can check that it is valid and that it belongs to the intended recipient. The client may also ask for any additional attributes it wants while it is querying the same server.
With the directory server known, the sender asks it for the attribute named vPIMrFC822Mailbox. The value is the email address to use, both in the message's To: field and in the SMTP RCPT command.
§3The Basic Send-and-Pray Service
The basic service relies upon NAPTR rewrite rules to mechanically construct a VPIM-specific email address. It is registered as E2U+VPIM:Mailto:, with URI type Mailto:, type VPIM and subtype MAILTO. To facilitate a full range of intradomain routing options, the constructed address indicates that the message is a VPIM message, and that indication SHOULD be in the domain name portion of the address, for ease of processing in the recipient's intradomain mail routing system.
The address is constructed using the address rewrite rules of the NAPTR records associated with the VPIM service. There is no assurance that the constructed address is valid, nor that the constructed address corresponds to the intended recipient. Because no capabilities information is provided about the recipient, messages sent with this mechanism SHOULD be sent using only the media and content types of the VPIM V2 profile, defined in RFC 3801.
The RFC lists three error conditions for the service: the E.164 number is not in the numbering plan, the E.164 number is in the numbering plan but no URLs exist for that number, or the E2U+VPIM:Mailto service is unavailable.
The basic service skips the directory. It uses a rewrite rule from the DNS to build an email address from the phone number, and the rule marks the address as a voice message. Nothing checks that the address is valid or belongs to the intended person, so the sender should use only the media types of the VPIM V2 profile.
§3.4Routing Inside the Recipient's Domain
The interdomain routing of a constructed VPIM address is mechanically indistinguishable from existing email routing. No changes to the infrastructure are required: the sending system consults the Domain Name System for an MX record corresponding to the domain name and forwards the message to the indicated system.
Within the recipient's domain, the message may be routed further to the appropriate messaging system. The RFC marks this subject as strictly informational, because intradomain routing is an internal matter for the domain and does not affect the protocol. It is only necessary that the addresses created by the NAPTR rewrite rules have meaning to the domain advertising them. Two general mechanisms are described.
- Directory-enabled routing: an inbound mail router of the recipient's domain uses the local part of the address to query for an internal mail address. That internal mail address is substituted for the SMTP RCPT address and used to deliver the message to the recipient mailbox. The mailbox does not need any knowledge of the mechanically constructed telephone-number-based address. Example address:
+12145551212@sp.net. - Service-based mail routing: a mail gateway is provisioned with a simple rule or small set of rules to forward all messages of a given service type to a predefined server, checking for the service name
VPIMas a prefix to the constructed domain name. That destination may be a single voice messaging server or a service-specific gateway into a larger telephone number-based voice-messaging network. Example address:+12145551212@VPIM.sp.net.
Between domains, delivery is ordinary email: the sender looks up the domain's MX record and forwards the message. Inside the recipient's domain, the RFC leaves the choice open. A mail router can look up an internal address in a directory, or a single rule can send every voice message to one server.
§4Security Considerations
There is little information disclosed to the sender of the message that is not already disclosed using standard email protocols. The ability to use this protocol to probe for valid addresses is identical to the sending of test messages and waiting for a non-delivery notification in return.
Two risks are called out. Unsolicited bulk email: the use of ENUM records to create routable email addresses from telephone numbers provides bulk mailers with the capability to send email to a large set of recipients where only the telephone number is known, or where telephone numbers are guessed. DNS-based attacks: both the complete and the basic service rely upon the DNS to provide the information needed to validate a recipient or send a message, and the message sender is a casual, unauthenticated user of the indicated servers. If the DNS is compromised, an attacker can redirect messages by providing a malicious email address or indicating a rogue directory with malicious LDAP URLs.
Use of the DNS security protocols described in RFC 4033 substantially reduces the risk of a domain being hijacked. If the E.164 zone is secured with DNSSEC, the attack is precluded if the client can trust the key used to sign the zone. DNS security does not protect against the LDAP service being independently compromised; the risk to that service is discussed in RFC 4237.
Both services depend on the DNS, so a tampered DNS can redirect a message to the wrong address. DNSSEC reduces that risk if the client trusts the signing key, but it does nothing if the directory server itself is compromised. Turning phone numbers into email addresses also gives bulk mailers a new list to target.
§5IANA Considerations
This specification registers the E2U+VPIM and E2U+Voice services according to the specifications and guidelines in RFC 3761 and the definitions in this document. Registering the names means that every implementation of either service uses the same strings.
The document registers the two service names, E2U+VPIM and E2U+Voice, with IANA under the rules in RFC 3761. Registering them means every implementation uses the same names.