Network Working Group H. Ryckelynck Internet-Draft Hubert Ryckelynck Intended status: Experimental June 7, 2012 Expires: December 9, 2012 Mail Accepted by Previous Sending draft-hryckelynck-mail-accepted-previous-sending-00 Abstract Mail Accepted by Previous Sending defines a mechanism by which incoming unsollicited mails may be rejected or penalized by a MTA if their sender address domains has never been a destination for the outgoing mails treated by this MTA. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 9, 2012. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Ryckelynck Expires December 9, 2012 [Page 1] Internet-Draft Mail Accepted by Previous Sending June 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. SMTP responsability notion . . . . . . . . . . . . . . . . . . 5 3.1. Original SMTP responsability notion . . . . . . . . . . . 5 3.1.1. responsibility of the client . . . . . . . . . . . . . 5 3.1.2. responsibility of the server . . . . . . . . . . . . . 5 3.2. gap is growing with the original notion . . . . . . . . . 5 3.2.1. silent dropping . . . . . . . . . . . . . . . . . . . 5 3.3. How to get back to the original notion . . . . . . . . . . 5 3.3.1. Does the return-path exists ? . . . . . . . . . . . . 5 3.3.2. Does the return-path has been sollicited ? . . . . . . 7 4. base format . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Base Fields . . . . . . . . . . . . . . . . . . . . . . . 9 5. Command to be used between MTA and BASE . . . . . . . . . . . 10 5.1. To Add information in the base . . . . . . . . . . . . . . 10 5.2. To Check information in the base . . . . . . . . . . . . . 10 6. Store informations about domains in the base . . . . . . . . . 11 6.1. automatically . . . . . . . . . . . . . . . . . . . . . . 11 6.2. accept a domain On demand . . . . . . . . . . . . . . . . 12 6.3. reject a domain On demand . . . . . . . . . . . . . . . . 13 6.4. Directly in the base . . . . . . . . . . . . . . . . . . . 13 7. Check the base and apply policy . . . . . . . . . . . . . . . 14 8. logical view . . . . . . . . . . . . . . . . . . . . . . . . . 17 9. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 18 9.1. Transparent mode . . . . . . . . . . . . . . . . . . . . . 18 9.2. base to be shared . . . . . . . . . . . . . . . . . . . . 18 9.3. Size of the base . . . . . . . . . . . . . . . . . . . . . 18 9.4. Notification . . . . . . . . . . . . . . . . . . . . . . . 18 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 11. Security Considerations . . . . . . . . . . . . . . . . . . . 20 11.1. IP reputation . . . . . . . . . . . . . . . . . . . . . . 20 11.2. SPF, Sender ID and DKIM . . . . . . . . . . . . . . . . . 20 11.3. Mail analysis . . . . . . . . . . . . . . . . . . . . . . 20 11.4. Authentification . . . . . . . . . . . . . . . . . . . . . 20 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 22 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23 Ryckelynck Expires December 9, 2012 [Page 2] Internet-Draft Mail Accepted by Previous Sending June 2012 1. Introduction It is easy to say that mails with, for example, an attempted fraud content are mails we must intercept. But for many other type of mail as, for example, marketing mail, it is very difficult to make the difference between a mail user wants to receive and a mail he does not want to receive. In fact, in a lot of cases, the only difference between sollicited and unsollicited mail is the recipient advice. With this in mind, it MAY be useful to find a mechanism for users to choose themselves who will be able to send them some mails. This mechanism SHOULD of course be implemented in a way the users do not feel too constrained. The mechanism described below is an attempt to give an answer to this problematic. Mail Accepted by Previous Sending defines a mechanism by which incoming unsollicited mails may be rejected or penalized by a MTA if their sender address domains has never been a destination for the outgoing mails treated by this MTA. Ryckelynck Expires December 9, 2012 [Page 3] Internet-Draft Mail Accepted by Previous Sending June 2012 2. Terminology The term "domain" use in this document has to be understand as the domain part of a SMTP address (user@domain) and must be a FQDN as describe in the section 2.3.5 of RFC 5321 [RFC5321]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. These words take their normative meanings only when they are presented in ALL UPPERCASE. Ryckelynck Expires December 9, 2012 [Page 4] Internet-Draft Mail Accepted by Previous Sending June 2012 3. SMTP responsability notion 3.1. Original SMTP responsability notion In the SMTP RFC [RFC5321], you will find a responsability notion. 3.1.1. responsibility of the client As Describe in the section 2.1 of RFC 5321 [RFC5321] : "The responsability of an SMTP client is to transfer mail messages to one or more SMTP servers, or report its failure to do so". 3.1.2. responsibility of the server As Describe in the section 2.1 of RFC 5321 [RFC5321] : "The protocol requires that a server MUST accept responsability for either delivering the message or properly reporting the failure to do so" As Describe in the section 6.1 of RFC 5321 [RFC5321] : When the receiver-SMTP accepts a piece of mail (by sending a "250 OK" message in response to DATA), it is accepting responsibility for delivering or relaying the message. It must take this responsibility seriously. 3.2. gap is growing with the original notion 3.2.1. silent dropping Because of the huge quantity of unsollicited mail and to avoid giving more information to those who are sending them, section 6.2 of RFC 5321 [RFC5321] permits in practice silent dropping and more and more MTAs are configured to drop silently those mails. 3.3. How to get back to the original notion 3.3.1. Does the return-path exists ? If section 6.2 of RFC 5321 [RFC5321] permits in practice silent dropping, it also pleads to keep the "delivered or returned" way to deal with mails. In this sense, those past years, efforts has been made to find some ways to check the return path as to stay close from the original SMTP responsability notion (deliver or notify). You of course need a Ryckelynck Expires December 9, 2012 [Page 5] Internet-Draft Mail Accepted by Previous Sending June 2012 return path in case of notify. But at this time the RFC 5321 [RFC5321]in section 3.6.2 doesn't recommend any method. A return-path is made of two independant elements, the user and the domain. What can be done if we want to check those two elements. 3.3.1.1. verification of the user part User part makes sense only for the MTA which finally delivers the mail. In the SMTP RFC [RFC5321] the VRFY command permits to ask a MTA about the user part. But to avoid giving more information to those who are sending unsollicited mail, the VRFY command has been disabled on most MTAs. The user part of the sender address is therefore uncheckable. 3.3.1.2. verification of the domain part There are four verification levels when checking domain : 1. Does the domain exist : First level is to verify if the domain is declared in the Internet DNS. This can be done by a DNS SOA Request 2. Does the domain has an MX record : Second level is to verify if the domain has declared that it can handle mail receiving. This can be done by a DNS MX request. 3. Does the domain has a declared MTA : Third level is to verify if the answer of the MX request, formerly the name of the server which will handle the mails, is properly declared on the Internet DNS. This can be done by a DNS A request. 4. Does the MTA is answering : Fourth level is to verify if the answer of the A request, formerly the IP address of the MTA, is accepting an SMTP connection. This can be done by a connection on the TCP port 25. Doing all of these verifications : o Will consume a lot of ressources. In fact as much work as to send a notification (except of the data). o will only prove that your correspondants have a fully compliant configuration. Ryckelynck Expires December 9, 2012 [Page 6] Internet-Draft Mail Accepted by Previous Sending June 2012 o Will not be disuasive for people who wants to send you some unsollicited mails as the cost to rent an MTA on Internet and to get a fully compliant Internet DNS configuration is very cheap and can be change regularly. Still the only thing that can definitively makes the difference between a sollicited and an unsollicited mail is the recipient advice. 3.3.2. Does the return-path has been sollicited ? 3.3.2.1. situation resume Briefly : o We MUST NOT drop messages without sending notifications. o So there SHOULD be a return path for notifications. o And it MAY be rational to verify this return path validity. o But today we can only check the domain part of the sender address. o And it is a very heavy process. 3.3.2.2. Mail accepted by previous sending To verify the domain and in the same time to be sure the user wants to comunicate with this domain we could apply the following mechanism. When mails are going out : o Take the domain part of the recipient address. o Store it, if not already store, in a base as accepted or rejected domains. Then when a mail is coming in : o Take the domain part of the sender address. o Check in the base if users accepted or rejected this domain o If some user accepted the domain, we MAY accept the mail. o If some user rejected the domain, we MAY reject and notify, or penalize the mail. Ryckelynck Expires December 9, 2012 [Page 7] Internet-Draft Mail Accepted by Previous Sending June 2012 This mechanism is fully compliant with RFC 5321 [RFC5321]. As Describe in the section 2.1 of RFC 5321 [RFC5321] : "The protocol requires that a server MUST accept responsability for either delivering the message or properly reporting the failure to do so" And in section 7.9 of RFC 5321 [RFC5321] : "It is a well-established principle that an SMTP server may refuse to accept mail for any operational or technical reason that makes sense to the site providing the server." And it has the advantage to give the user the possibility to explicitly declare what is for him a sollicited mail. Ryckelynck Expires December 9, 2012 [Page 8] Internet-Draft Mail Accepted by Previous Sending June 2012 4. base format 4.1. Base Fields This part describes the fields to be present in the base. +------+ +------+-----------+-------+-----------+-------+----+ | NAME | |Domain|Over-Accept|Accept |Over-Reject| Reject|Date| +------+ +------+-----------+-------+-----------+-------+----+ | TYPE | | Text | Boolean |Integer| Boolean |Integer|Date| +------+ +------+-----------+-------+-----------+-------+----+ o Domain : as described in section 3.1 of RFC 1035 [RFC1035]. o Over-Accept : If True, Administrator overrided domain accept. o Accept : Number of time domain has been accepted. o Over-Reject : If True, Administrator overrided domain reject. o Reject : Number of time domain has been rejected. o Date : Last time record was updated. Ryckelynck Expires December 9, 2012 [Page 9] Internet-Draft Mail Accepted by Previous Sending June 2012 5. Command to be used between MTA and BASE This part describes the commands to be used between MTA and base. 5.1. To Add information in the base Command : ADD (DOMAIN,ACCEPT,REJECT,DATE) Return Type : NONE Description : Add information about a domain in the base. 5.2. To Check information in the base Command : DOMAIN() Return Type : BOOLEAN Description : Does the domain exist in the base ? Command : OVER_REJECT() Return Type : BOOLEAN Description : Did administrator override domain reject ? Command : OVER_ACCEPT() Return Type : BOOLEAN Description : Did administrator override domain accept ? Command : NB_ACCEPT() Return Type : INTEGER Description : How many time domain has been accepted ? Command : NB_REJECT() Return Type : INTEGER Description : How many time domain has been rejected ? Ryckelynck Expires December 9, 2012 [Page 10] Internet-Draft Mail Accepted by Previous Sending June 2012 6. Store informations about domains in the base 6.1. automatically Anytime a user sends an outgoing mail, a filter on MTA intercepts it and adds the domain part of the recipient adress as accepted in the base. +----+ 2-ADD(DOMAIN,1,0,DATE) |BASE|<---------------------+ +----+ | | ## MTA ##################################|## # +------- FILTER -------+ | # # | +------------------+ | | # # | | IF(ANY) | | | # ##### 1-SEND | +------------------+ | | # #MUA#----------------->| +------------------+ | | # ##### # | | |---------+ # # | | THEN | | 3-DELIVER # | | |----------------> # | +------------------+ | # # +----------------------+ # ############################################ 1. Anytime user sends an outgoing mail. 2. MTA intercepts it and adds in base the following informations : * recipient address domain (if not already in the base). * parameter ACCEPT="1" to increment the "Accept" base field. * parameter REJECT="0" to not increment the "Reject" base field. * Current date to update, if necessary, the "Date" base field. 3. MTA delivers the mail. Ryckelynck Expires December 9, 2012 [Page 11] Internet-Draft Mail Accepted by Previous Sending June 2012 6.2. accept a domain On demand For mail like newsletter to which user never answers, user sends an outgoing mail with a specific header, a filter intercepts the mail, and adds the domain part of the recipient adress as accepted in the base. +----+ ADD(DOMAIN,1,0,DATE) |BASE|<-------------------+ +----+ | | ## MTA ##################################|## # +------- FILTER -------+ | # # | +------------------+ | | # # | |IF(HEADER="ACCEPT"| | | # ##### 1-SEND WITH | +------------------+ | | # #MUA#----------------->| +------------------+ | | # ##### "ACCEPT" HEADER | | |---------+ # # | | THEN | | # # | | |--->3-DROP # # | +------------------+ | # # +----------------------+ # ############################################ 1. User sends an outgoing mail with an "ACCEPT" header. 2. MTA intercepts it and adds in base the following informations : * recipient address domain (if not already in the base). * parameter ACCEPT="1" to increment the "Accept" base field. * parameter REJECT="0" to not increment the "Reject" base field. * Current date to update, if necessary, the "Date" base field. 3. MTA drops the mail. Remark : The number of domains to be declared this way by user would be in most cases very small. Ryckelynck Expires December 9, 2012 [Page 12] Internet-Draft Mail Accepted by Previous Sending June 2012 6.3. reject a domain On demand To declare a mail as Unsollicited, user sends an outgoing mail with a specific header, a filter intercepts the mail and adds the domain part of the recipient adress as rejected in the base. +----+ 2-ADD(DOMAIN,0,1,DATE) |BASE|<---------------------+ +----+ | | ## MTA ##################################|## # +------- FILTER -------+ | # # | +------------------+ | | # # | |IF(HEADER="REJECT"| | | # ##### 1-SEND WITH | +------------------+ | | # #MUA#----------------->| +------------------+ | | # ##### "REJECT" HEADER | | |---------+ # # | | THEN | | # # | | |--->3-DROP # # | +------------------+ | # # +----------------------+ # ############################################ 1. User sends an outgoing mail with an "REJECT" header. 2. MTA intercepts it and adds in base the following informations : * recipient address domain (if not already in the base). * parameter ACCEPT="0" to not increment the "Accept" base field. * parameter REJECT="1" to increment the "Reject" base field. * Current date to update, if necessary, the "Date" base field. 3. MTA drops the mail. Remark : The number of domains to be declared this way by user would be in most cases very small. 6.4. Directly in the base The MTA administrator will of course have the possibility to add a domain directly in the base. Ryckelynck Expires December 9, 2012 [Page 13] Internet-Draft Mail Accepted by Previous Sending June 2012 7. Check the base and apply policy +---++---+ |O|A||O|R| 1.6 +--------|-+-||-+-| +--------->|dom1.com|F|1||F|0| | 2.2 |--------|---||---| 2.1 | +--------|dom2.com|F|1||F|0|<--------+ | | 7.2 |--------|---||---| 7.1 | | | +------|dom7.com|T|0||F|0|<------+ | | | | 1.2 |--------|---||---| 1.1 | | | | | +----|????.???|?|?||?|?|<----+ | | | | | |4.2 |--------|---||---| 4.1 | | | | | | | +--|dom4.com|F|1||F|2|<--+ | | | | | | | | +--------+---++---+ | | | | | | | | | | | | | 1.5 #|#|#|#|#|########## MTA #########|#|#|#|# +-----------------+ | | | | | | | +-- | # | | | | | | | # ####|# MUA ######## # | | | | | | +---- # | +----+<------+ | | | | | # # | +--->| IN | # # | | +---------+ | +------ # | |1.4 +----+<--------+ | | | # # +------+ # # | | | # # |ACCEPT|<----+ # # +--------+ | +-------- # +------+ 1.3 | # # | | # # +----+ # # +----------+ | | # # |NEW |<-----|NEW HEADER|<-+ | # # +----+ # # +----------+ | # # +------+ 1.7 | # # | +--->+--------+ # # |REJECT|<----+ # # | | |REJECTED|--> # +------+ # # | | +->+--------+ # # | |1.8 +----+<-----+-----------+<---+ | | # # | +--->|JUNK| # # |JUNK HEADER| | | +------ # | +----+<-----+-----------+<---+ | | | # ####|############## # | | | | +---- | # +---------------+ | | | | # +-----------------+ | +-------------------+ | | | # 1.9 #| | | +-------------------+ | | +-- #|#|#|#|############################|#|#|# | | | | | | | | | | |5.2 +--------+---++---+ 5.1 | | | | | | +----|dom5.com|F|0||F|5|<----+ | | | | | 6.2 |--------|---||---| 6.1 | | | | +------|dom6.com|F|0||T|0|<------+ | | | 3.2 |--------|---||---| 3.1 | | +--------|dom3.com|F|0||F|1|<--------+ | |--------|---||---| +--------->|dom1.com|F|0||F|1| 1.10 +--------|---||---| |O|A||O|R| +---++---+ Ryckelynck Expires December 9, 2012 [Page 14] Internet-Draft Mail Accepted by Previous Sending June 2012 1. 1. Mail arrives from @dom1.com, MTA sees dom1.com is not in the base. 2. MTA adds a "NEW" header and sends it to the MUA. A rule on the MUA identifies the header and puts the mail in the "NEW" Box. 3. If user clicks on "ACCEPT" button To declare this mail is sollicited. 4. MUA puts the mail in the "IN" Box. 5. MUA sends an outgoing mail to the domain with an "accepted" header. 6. A rule on the MTA identifies the header, intercepts the mail, adds the domain in the base and declares it as accepted (+1 in the column A). 7. If user clicks on "REJECT" button To declare this mail is unsollicited. 8. MUA puts the mail in the "JUNK" Box. 9. MUA sends an outgoing mail to the domain with a "rejected" header. 10. A rule on the MTA identifies the header, intercepts the mail, adds the domain in the base and declares it as rejected (+1 in the column R). 2. 1. Mail arrives from @dom2.com, MTA sees in the base domain has been accepted (column A=1) and never rejected (column R=0). 2. MTA sends it to MUA and MUA puts the mail in the "IN" Box Ryckelynck Expires December 9, 2012 [Page 15] Internet-Draft Mail Accepted by Previous Sending June 2012 3. 1. Mail arrives from @dom3.com. MTA sees in the base domain has been rejected (column R=1) and never accepted (column A=0). 2. MTA adds a "junk" header and send it to MUA. A rule on the MUA identifies the header and puts the mail in the "JUNK" Box. 4. 1. Mail arrives from @dom4.com, MTA sees in the base domain has been rejected 2 times (column R=2) but has also been accepted 1 time (column A=1). 2. MTA adds a "junk" header and sends it to the MUA. A rule on the MUA identifies the header and puts the mail in the "junk" Box. 5. 1. Mail arrives from @dom5.com, MTA sees in the base domain has been rejected 5 times (column R=5) and never accepted (column A=0). 2. If 5 is more than the limit the administrator fixed, mail is rejected. 6. 1. Mail arrives from @dom6.com, MTA sees in the base domain has been rejected by administrator override (column O=T). 2. Mail is rejected. 7. 1. Mail arrives from @dom7.com, MTA sees in the base domain has been accepted by administrator override (column O=T). 2. MTA sends it to MUA and MUA puts the mail in the "IN" Box. Ryckelynck Expires December 9, 2012 [Page 16] Internet-Draft Mail Accepted by Previous Sending June 2012 8. logical view INCOMING MAIL | +--------+ | | FALSE |DOMAIN()|-------> Add "NEW" header and deliver. | | +--------+ | TRUE | +--------+ | | TRUE | OVER_ |------> Reject. |REJECT()| +--------+ | FALSE | +--------+ | | TRUE | OVER_ |------> Deliver. |ACCEPT()| +--------+ | FALSE | +--------+ +--------+ | NB_ | FALSE | NB_ | TRUE |REJECT()|------>|ACCEPT()|------> Deliver. | >0 | | >0 | +--------+ +--------+ | | FALSE | TRUE +----------> Add "JUNK" header and deliver. | +--------+ +--------+ | NB_ | FALSE | NB_ | TRUE |ACCEPT()|------>|REJECT()|------> Reject. | >0 | | > MAX | +--------+ +--------+ | | FALSE | +----------> Add "JUNK" header and deliver. | TRUE +-----> Add "JUNK" header and deliver. Ryckelynck Expires December 9, 2012 [Page 17] Internet-Draft Mail Accepted by Previous Sending June 2012 9. Recommendations 9.1. Transparent mode When a company wants to implement this mechanism. It SHOULD, at the beginning, activate only the "Automatically" mode (see 4.1) without applying any policy. During a period of time, the base will be automatically filled with accepted domain. At the beginning the size of the base will grow up very fast. After a while, when the growing of the base will slow down, the MTA administrator could then : o Communicate to users the way to accept or reject domain. o Start to reject or penalize non previoulsy accepted domain. 9.2. base to be shared Information in the Base SHOULD be sharable by all MTA in a same company. 9.3. Size of the base To limit the size of the base, the Date field can be used to delete oldest records. 9.4. Notification If you make the choice, considering the information in the base, to reject the mail, you MUST return a 5.5.0 code as Describe in the section 3.6.2 of RFC 5321 [RFC5321]. Ryckelynck Expires December 9, 2012 [Page 18] Internet-Draft Mail Accepted by Previous Sending June 2012 10. IANA Considerations This document has no action for IANA. Ryckelynck Expires December 9, 2012 [Page 19] Internet-Draft Mail Accepted by Previous Sending June 2012 11. Security Considerations 11.1. IP reputation Ip reputation mechanism will still protect you against massive sending. Without this mechanism the domain verification process could be a target for Deny of service attack. 11.2. SPF, Sender ID and DKIM It is not garanteed, when a mail which has a sender address from a domain you previously accepted, that this mail really come from this domain. For this purpose you may need other mechanism that could be viewed as complementary like Sender ID [RFC4406], SPF [RFC4408] or DKIM [RFC6376]. 11.3. Mail analysis Mail analysis is still needed, as a previously accepted domain MAY have been temporarly corrupted and MAY send you temporarly unsollicited mail. 11.4. Authentification The possibility you give to user to authorize a domain just by sending a mail SHOULD be limited to authentified user. Ryckelynck Expires December 9, 2012 [Page 20] Internet-Draft Mail Accepted by Previous Sending June 2012 12. References [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4406] Lyon, J. and M. Wong, "Sender ID: Authenticating E-Mail", RFC 4406, April 2006. [RFC4408] Schlitt, W. and M. Wong, "Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail", RFC 4408, May 2006. [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, November 2008. [RFC6376] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys Identified Mail (DKIM) Signatures", RFC 6376, September 2011. Ryckelynck Expires December 9, 2012 [Page 21] Internet-Draft Mail Accepted by Previous Sending June 2012 Appendix A. Acknowledgements The author gratefully acknowledges the contributions of: S. Moonesamy Ryckelynck Expires December 9, 2012 [Page 22] Internet-Draft Mail Accepted by Previous Sending June 2012 Author's Address Hubert Ryckelynck Hubert Ryckelynck 40 Avenue de la Grande Armee Paris, 75017 FRANCE Phone: Email: hub.ryck@gmail.com URI: Ryckelynck Expires December 9, 2012 [Page 23]