RFC 4238

Voice Message Routing Service

📅 published October 2005, from ietf

RFC 4238: Voice Message Routing Service 💌

Okay bestie, this is RFC 4238, and it's giving phone calls meet email 📞✨. It's a Standards Track document by G. Vaudreuil of Lucent Technologies, dated October 2005. The original title block doesn't list anything it obsoletes or updates, so it's a fresh start 🌸.

Status of This Memo 🎀

This document specifies an Internet standards track protocol for the Internet community, and it wants your discussion and suggestions for improvements 🫶. For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌈.

Copyright (C) The Internet Society (2005).

Abstract ✨

Voice messaging has traditionally been addressed with telephone numbers, which is so classic 📱. This document describes two techniques for routing voice messages based on a telephone number 🦋.

The complete service is the main character 👑. It uses the Voice Profile for Internet Mail (VPIM) Directory service to look up a VPIM email address from a telephone number, then confirms that the address is both valid and associated with the intended recipient. The catch is that this service will take time to become widely deployed in the near term 😭.

The document also describes a basic send-and-pray service 🙈. It 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 meant to give you 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 figure out the VPIM directory. Then it uses LDAP to pull the VPIM-specific email address that gets used for message routing 👑.

The more basic send-and-pray message service only uses the ENUM service and MX records to route the message to the recipient's domain 🙈. The intelligence to route the message the rest of the way to the intended recipient lives inside the message routing system of the recipient's domain 🧠.

The basic mechanism may be used even when a VPIM directory service is available 💖. It's useful when LDAP queries aren't available, which can happen with disconnected mobile terminals, or because of firewall or information security policies 🔒.

The basic mechanism should make it easy to route VPIM messages to a suitable internal destination with minimal configuration ✨. It's a big goal to avoid any content processing to work out what kind of message it is and where it's headed internally 🙅‍♀️. At a minimum, it should be possible to set up a simple mail forwarding rule that sends all inbound VPIM messages to one designated system. Meanwhile, it still makes routing FAX, SMS, or other telephone-addressed messages to other, potentially different, systems easy 📠.

It's also a goal that the mechanisms in this document be extensible for all store-and-forward, telephone-number addressed messaging services 🌸.

Finally, the VPIM directory discovery and VPIM directory query steps should happen 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. Then the client should query that server for the email address and any additional attributes it wants 🫶.

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:
    • Malicious Redirection

Okay, this one is scary 😱. One of the fundamental dangers with any service like this is that a malicious entry in a resolver's database could make clients resolve the E.164 into the wrong LDAP URL. The possible intent is to get the client to connect to a rogue LDAP server, then retrieve (or fail to retrieve) a resource containing fraudulent or damaging information 🚨.

  • Denial of Service

Also rude 💀. By removing the URL that the E.164 maps to, a malicious intruder could take away the client's ability to reach 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 recipient's telephone number 📞.

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 🔢.

Here's an 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 let you give two records for the same service and preference different weights ⚖️. You can give the same weight to both if you want 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's 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 on NAPTR rewrite rules to mechanically construct a valid VPIM-specific email address ⚙️. Inside the recipient's domain, the constructed address may be routed further using intradomain mail routing techniques 🏠.

To make a full range of intradomain routing options possible, the constructed email address shows 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 💖.

Okay, big warning here 🚩: there is no assurance that the constructed address is valid, or that it 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:
    • E.164 number not in the numbering plan
    • E.164 number in the numbering plan, but no URLs exist for that number
    • E2U+VPIM:Mailto Service unavailable
  • Security Considerations:
    • Malicious Redirection

Same energy as before 😬. One of the fundamental dangers with any service like this is that a malicious entry in a resolver's database could make clients resolve the E.164 into the wrong email URL. The possible intent is to get the client to send information to an incorrect destination 📤.

  • Denial of Service

By removing the URL that the E.164 maps to, a malicious intruder could take away the client's ability to access the resource 🙅‍♀️.

  • Unsolicited Bulk Email

This one's a whole mood 📧💀. Exposing email addresses through the ENUM service gives bulk mailers access to large numbers of email addresses where only telephone numbers used to be 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 🌍

Interdomain routing of a constructed VPIM address is mechanically indistinguishable from existing email routing 🥰. No changes to the infrastructure are required. The sending system looks up an MX record for the domain name in the Domain Name System, then forwards the message to the system it names 📮.

3.4. Intradomain Message Routing 🏡

Within the recipient's domain, the message may be routed further to the appropriate messaging system 🧭. Two general mechanisms may be used to 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 creating and using such addresses may be useful 🤓.

3.4.1. Directory-Enabled Routing 📇

Various proprietary directory mechanisms give an inbound mail router in the recipient's domain a way 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 it's used to deliver the message to the recipient mailbox 📥. Note that the mailbox doesn't need to know anything about the mechanically constructed telephone number-based address 🤫.

Example address:

+12145551212@sp.net

3.4.2. Service-based Mail Routing 🦋

Okay so, there's also a simpler option, bestie! A mail gateway can just toss all the voice messages into a separate messaging system 📬. That system could be one single voice messaging server, or a service-specific gateway into a bigger telephone number-based voice-messaging network ☎️✨.

The gateway can be set up with one simple rule, or a small set of rules, that forwards every message of a given service type to a pre-defined server 🎯. This rule looks for the service name "VPIM" as a prefix on the constructed domain name, and that's how it reroutes the messages 🔀.

Example address:

+12145551212@VPIM.sp.net

4. Security Considerations 🛡️

Okay, security time, and it's giving very careful 🫶. There's not a lot of info given to the sender that isn't already out there with standard email protocols 📧. And using this protocol to probe for valid addresses is basically the same as sending test messages and waiting to see if a non-delivery notification comes back 🙈.

4.1. Unsolicited Bulk Email 📢

Now here's the spicy part 🌶️. Using ENUM records to build routable email addresses from telephone numbers gives bulk-emailers a whole toolkit. They can send email to a huge set of recipients when all they know is the telephone number, or when they're just guessing telephone numbers 💀.

4.2. DNS-based Attacks 🕸️

Both the complete and basic services depend on the DNS to supply the info needed to validate a recipient or send a message 🌐. The message sender is a casual, unauthenticated user of the servers listed, and it relies on the DNS for accurate information 🙃. If the DNS gets compromised, an attacker can redirect messages by handing out a malicious email address or pointing to a rogue directory with malicious LDAP URL's 😱.

Using DNS Security protocols [DNSSEC] seriously cuts down the risk of a domain getting hijacked 🔐. If the E.164 zone is secured with DNSSEC, the attack is shut down as long as the client can trust the key used to sign the zone 💅. But DNS security doesn't protect against the LDAP service being compromised on its own 🚨. More on the risk to this LDAP service is in [VPIMDIR] 📚.

5. IANA Considerations 📋

This spec registers the E2U+VPIM and E2U+Voice services, following the specifications and guidelines in RFC 3761 [ENUM] plus 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 doc 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 💖

Copyright (C) The Internet Society (2005) 🌈.

This doc is covered by the rights, licenses and restrictions in BCP 78, and apart from what's set out there, the authors keep all their rights 🦋.

The doc and the info in it are provided "AS IS", 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. That includes, but isn't limited to, any warranty that using the info here won't infringe any rights, and any implied warranties of merchantability or fitness for a particular purpose 😭.

Intellectual Property 🎀

The IETF doesn't take a position on whether any Intellectual Property Rights or other rights claimed to cover the implementation or use of the tech in this doc are valid or in scope, or on whether any license under those rights is available. It also doesn't claim to have done any independent search for such rights 🔍. Info on the procedures for rights in RFC docs is in BCP 78 and BCP 79 📖.

Copies of IPR disclosures sent to the IETF Secretariat, any assurances of licenses that will be available, and the results of any attempt to get a general license or permission for implementers or users of this spec to use those proprietary rights can be found in the IETF on-line IPR repository at http://www.ietf.org/ipr 🔗.

The IETF invites anyone interested to point out any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org 💜.

Acknowledgement 🌷

Funding for the RFC Editor function is currently provided by the Internet Society 🥰✨.

📦 where this page comes from