idnits 2.17.1 draft-ietf-sieve-external-lists-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 29, 2011) is 4776 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFCXXXX' is mentioned on line 451, but not defined ** Downref: Normative reference to an Informational RFC: RFC 4151 ** Obsolete normative reference: RFC 4395 (Obsoleted by RFC 7595) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Sieve Working Group A. Melnikov 3 Internet-Draft Isode Limited 4 Intended status: Standards Track B. Leiba 5 Expires: September 30, 2011 Huawei Technologies 6 March 29, 2011 8 Sieve Extension: Externally Stored Lists 9 draft-ietf-sieve-external-lists-06 11 Abstract 13 The Sieve scripting language can be used to implement whitelisting, 14 blacklisting, personal distribution lists, and other sorts of list 15 matching. Currently, this requires that all members of such lists be 16 hardcoded in the script itself. Whenever a member of a list is added 17 or deleted, the script needs to be updated and possibly uploaded to a 18 mail server. 20 This document defines a Sieve extension for accessing externally 21 stored lists -- lists whose members are stored externally to the 22 script, such as using LDAP (RFC 4510), ACAP (RFC 2244), or relational 23 databases. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on September 30, 2011. 42 Copyright Notice 44 Copyright (c) 2011 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Conventions Used In This Document . . . . . . . . . . . . 3 62 2. Extlists Extension . . . . . . . . . . . . . . . . . . . . 3 63 2.1. Capability Identifier . . . . . . . . . . . . . . . . . . 3 64 2.2. :list Match Type for Supported Tests . . . . . . . . . . . 3 65 2.3. :list Tagged Argument to the "redirect" Action . . . . . . 4 66 2.4. Other Uses for External Lists . . . . . . . . . . . . . . 5 67 2.5. Syntax of an Externally Stored List Name . . . . . . . . . 5 68 2.6. Test valid_ext_list . . . . . . . . . . . . . . . . . . . 6 69 2.7. Interaction with ManageSieve . . . . . . . . . . . . . . . 6 70 2.8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 2.8.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 7 72 2.8.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 8 73 2.8.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . . . 8 75 3. Security Considerations . . . . . . . . . . . . . . . . . 8 77 4. IANA Considerations . . . . . . . . . . . . . . . . . . . 9 78 4.1. Registration of Sieve Extension . . . . . . . . . . . . . 10 79 4.2. Registration of ManageSieve Capability . . . . . . . . . . 10 80 4.3. Registration of "ab" URI Scheme . . . . . . . . . . . . . 11 82 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 12 84 6. References . . . . . . . . . . . . . . . . . . . . . . . . 12 85 6.1. Normative References . . . . . . . . . . . . . . . . . . . 12 86 6.2. Informative References . . . . . . . . . . . . . . . . . . 13 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 14 90 1. Introduction 92 This document specifies an extension to the Sieve language [RFC5228] 93 for checking membership in an external list or for redirecting 94 messages to an external list of recipients. An "external list" is a 95 list whose members are stored externally to the Sieve script, such as 96 using LDAP [RFC4510], ACAP [RFC2244], or relational databases. 98 This extension adds a new match type to apply to supported tests, and 99 a new tagged argument to the "redirect" action. 101 1.1. Conventions Used In This Document 103 Conventions for notations are as in [RFC5228] section 1.1, including 104 the use of [RFC5234]. 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in [RFC2119]. 110 2. Extlists Extension 112 2.1. Capability Identifier 114 The capability string associated with the extension defined in this 115 document is "extlists". 117 2.2. :list Match Type for Supported Tests 119 ABNF: 121 MATCH-TYPE =/ ":list" 122 ; only valid for supported tests 124 The new ":list" match type changes the interpretation of the "key- 125 list" parameter (the second parameter) in supported tests. When the 126 match type is ":list", the key-list becomes a list of names of 127 externally stored lists. The external lists are queried, perhaps 128 through a list-specific mechanism, and the test evaluates to "true" 129 if any of the specified values matches any member of one or more of 130 the lists. 132 Comparators are not allowed together with the ":list" match type, so 133 if both are specified in a test, that MUST result in an error. 134 Queries done through list-specific mechanisms might have the effect 135 of built-in comparators; for example, queries to certain lists might 136 be case-sensitive, while queries to other lists might be done without 137 regard to case. 139 Implementations MUST support the use of :list in "address", 140 "envelope" and "header" tests. Implementations that include the 141 Variables extension [RFC5229] MUST also support its use in "string" 142 tests. 144 Implementations MAY support other tests but MUST raise an error 145 (which SHOULD be a compile-time error, but MAY be a runtime error) 146 when a script uses :list with a test for which it is not supported. 147 To maintain interoperability, other tests that can be used with :list 148 SHOULD be documented in a specification that defines a capability 149 string that can be tested (in a "require" statement, or using ihave 150 [RFC5463]). 152 For example, testing 'header ["to", "cc"]' against a list would cause 153 each "to" and "cc" value, ignoring leading and trailing whitespace, 154 to be queried. If any value is found to belong to the list, the test 155 returns "true". If no value belongs to the list, the test returns 156 "false". Once a value is found in the list, there is no need for the 157 query mechanism to look further. 159 For some lists, the Sieve engine might directly retrieve the list and 160 make its own comparison. Other lists might not work that way -- they 161 might provide a way to ask if a value is in the list, but not permit 162 retrieval of the list itself. It is up to the Sieve implementation 163 to understand how to interact with any supported list. If the Sieve 164 engine is permanently unable to query the list (perhaps because the 165 list doesn't support the required operation), the test MUST result in 166 a runtime error in the Sieve script. 168 See Section 2.5 for the detailed description of syntax used for 169 naming externally stored lists. 171 The :list match type uses the concept of "match variables" as defined 172 in Section 3.2 of the Variables extension [RFC5229]. Implementations 173 that also support that extension MUST set the ${0} match variable to 174 the value in the list that matched the query. Other numbered match 175 variables (${1}, ${2}, and so on) MAY be set with list-specific 176 information that might be of use to the script. 178 2.3. :list Tagged Argument to the "redirect" Action 180 Usage: redirect :list 182 The "redirect" action with the ":list" argument is used to send the 183 message to the set of email addresses in the externally stored list 184 named by the ext-list-name string. This variant of the redirect 185 command can be used to implement a personal distribution list. 187 For this feature to work, one of the following conditions has to be 188 true: 190 1. The list resolves to a list of email addresses, and the Sieve 191 engine is able to enumerate those addresses. 193 2. The list handler is able to take care of the redirection on 194 behalf of the Sieve engine. 196 In cases where, for example, a list contains hashed email address 197 values or an email address pattern ("sz*@example.com", 198 "*+ietf@example.net"), the Sieve engine will not be able to redirect 199 to that list, and responsibility must pass to the list handler. 201 If neither the Sieve engine nor the list handler can enumerate (or 202 iterate) the list, or the list does not resolve to email addresses, 203 the situation MUST result in a runtime error in the Sieve script. 205 See Section 2.5 for the detailed description of syntax used for 206 naming externally stored lists. 208 2.4. Other Uses for External Lists 210 The uses for external lists specified here represent the useful cases 211 and situations at the time of this writing. Other uses for external 212 lists, using other Sieve features, might be devised in the future, 213 and such uses can be described in extensions to this document. 215 2.5. Syntax of an Externally Stored List Name 217 A name of an externally stored list is always an absolute URI 218 [RFC3986]. Implementations might find URIs such as LDAP [RFC4510], 219 CardDAV [I-D.ietf-vcarddav-carddav], or Tag [RFC4151] to be useful 220 for naming external lists. 222 The "tag" URI scheme [RFC4151] can be used to represent opaque, but 223 user friendlier identifiers. Resolution of such identifiers is going 224 to be implementation specific and it can help in hiding the 225 complexity of an implementation from end users. For example, an 226 implementation can provide a web interface for managing lists of 227 users stored in LDAP. Requiring users to know generic LDAP URI 228 syntax might not be very practical, due to its complexity. An 229 implementation can instead use a fixed tag URI prefix such as "tag: 230 example.com,:" (where can be, for example, a date 231 generated once on installation of the web interface and left 232 untouched upon upgrades) and the prefix doesn't even need to be shown 233 to end users. 235 The "ab" URI scheme (in particular, the URI "ab:default"), defined in 236 Section 4.3 MUST be supported. The mandatory-to-implement URI "ab: 237 default" gives access to the user's default address book (usually the 238 user's personal address book). 240 It's possible that a server will have no access to anything 241 resembling an address book (perhaps in an implementation where 242 address books are only client-side things), but the server can still 243 provide access to other sorts of lists -- consider the list of dates 244 in Example 2 (Section 2.8.2), or lists of important keywords and the 245 like. It might sometimes make sense to map "ab:default" into some 246 available list, but that might not always be reasonable. If there 247 really is no concept of an address book in a particular server 248 implementation, the server MAY support "ab:default" by having all 249 matches to it fail. Such an implementation SHOULD NOT be done except 250 as a last resort. 252 Queries against address books SHOULD be done without regard to case. 254 2.6. Test valid_ext_list 256 Usage: valid_ext_list 258 The "valid_ext_list" test is true if all of the external list names 259 in the ext-list-names argument are supported, and they are valid both 260 syntactically (including URI parameters) and semantically (including 261 implementation-specific semantic restrictions). Otherwise the test 262 returns false. 264 This test MUST perform exactly the same validation of an external 265 list name as would be performed by the "header :list" test. 267 2.7. Interaction with ManageSieve 269 This extension defines the following new capability for ManageSieve 270 (see [RFC5804] section 1.7): 272 EXTLISTS - A space-separated list of URI schema parts [RFC3986] for 273 supported externally stored list types. This capability MUST be 274 returned if the corresponding Sieve implementation supports the 275 "extlists" extension defined in this document. 277 This also extends the ManageSieve ABNF as follows: 279 single-capability =/ DQUOTE "EXTLISTS" DQUOTE SP ext-list-types CRLF 280 ; single-capability is defined in [RFC5804] 282 ext-list-types = string 283 ; space separated list of URI schema parts 284 ; for supported externally stored list types. 285 ; MUST NOT be empty. 287 2.8. Examples 289 2.8.1. Example 1 291 This example uses a personal address book, along with the Spamtest 292 [RFC5235] and Relational [RFC5231] extensions to give a different 293 level of spam tolerance to known senders. 295 require ["envelope", "extlists", "fileinto", "spamtest", 296 "relational", "comparator-i;ascii-numeric"]; 297 if envelope :list "from" "ab:default" 298 { /* Known: allow high spam score */ 299 if spamtest :value "ge" :comparator "i;ascii-numeric" "8" 300 { 301 fileinto "spam"; 302 } 303 } 304 elsif spamtest :value "ge" :comparator "i;ascii-numeric" "3" 305 { /* Unknown: less tolerance in spam score */ 306 fileinto "spam"; 307 } 309 The same example can also be written another way, if the Variables 310 extension [RFC5229] is also supported: 312 require ["envelope", "extlists", "fileinto", "spamtest", 313 "variables", "relational", "comparator-i;ascii-numeric"]; 314 if envelope :list "from" "ab:default" { 315 set "limit" "8"; /* Known: allow high spam score */ 316 } else { 317 set "limit" "3"; /* Unknown: less tolerance in spam score */ 318 } 319 if spamtest :value "ge" :comparator "i;ascii-numeric" ${limit} { 320 fileinto "spam"; 321 } 323 2.8.2. Example 2 325 This example uses the "currentdate" test [RFC5260] and a list 326 containing the dates of local holidays. If today is a holiday, the 327 script will notify [RFC5435] the user via XMPP [RFC5437] about the 328 message. 330 require ["extlists", "date", "enotify"]; 331 if currentdate :list "date" 332 "tag:example.com,2011-01-01:localHolidays" { 333 notify "xmpp:romeo@im.example.com"; 334 } 336 2.8.3. Example 3 338 This example also uses the "envelope" option [RFC5228] and the 339 Subaddress extension [RFC5233]. If mail is sent with the list name 340 as a subaddress of the recipient (to, say, "alexey+mylist"), and the 341 message comes from a member of the list, it will be redirected to all 342 members of the list. Variants of this technique might be useful for 343 creating private mailing lists. 345 require ["extlists", "envelope", "subaddress"]; 347 # Submission from list members is sent to all members 348 if allof (envelope :detail "to" "mylist", 349 header :list "from" 350 "tag:example.com,2010-05-28:mylist") { 351 redirect :list "tag:example.com,2010-05-28:mylist"; 352 } 354 3. Security Considerations 356 Security considerations related to the "address"/"envelope"/"header" 357 tests and "redirect" action discussed in Sieve [RFC5228] also apply 358 to this document. 360 External list memberships ought to be treated as if they are an 361 integral part of the script, so a temporary failure to access an 362 external list SHOULD be handled in the same way as a temporary 363 failure to retrieve the Sieve script itself. 365 For example, if the Sieve script is stored in the Lightweight 366 Directory Access Protocol [RFC4510] and the script can't be retrieved 367 when a message is processed (perhaps the LDAP server is unavailable), 368 then the Sieve engine might delay message delivery until the script 369 can be retrieved successfully. Similarly, if an external list is 370 stored in LDAP and that LDAP server is unavailable, the Sieve engine 371 would take the same action -- delay message delivery and try again 372 later. 374 Protocols/APIs used to retrieve/verify external list membership MUST 375 provide an appropriate level of confidentiality and authentication. 376 Usually, that will be at least the same level of confidentiality as 377 protocols/APIs used to retrieve Sieve scripts, but only the 378 implementation (or deployment) will know what is appropriate. 379 There's a difference, for example, between making an LDAP request on 380 a closed LAN that's only used for trusted servers (it may be that 381 neither encryption nor authentication is needed), on a firewalled LAN 382 internal to a company (it might be OK to skip encryption, depending 383 upon policy), and on the open Internet (encryption and authentication 384 are probably both required). It also matters whether the list being 385 accessed is private or public (no encryption or authentication may be 386 needed for public data, even on the Internet). 388 Implementations of this extension should keep in mind that matching 389 values against an externally stored list can be IO and/or CPU 390 intensive. This can be used to deny service to the mailserver and/or 391 to servers providing access to externally stored mailing lists. A 392 naive implementation, such as the one that tries to retrieve content 393 of the whole list to perform matching can make this worse. 395 But note that many protocols that can be used for accessing 396 externally stored lists support flexible searching features that can 397 be used to minimize network traffic and load on the directory 398 service. For example, LDAP allows for search filters. 399 Implementations SHOULD use such features whenever they can. 401 Many organizations support external lists with thousands of 402 recipients. In order to avoid mailbombs when redirecting a message 403 to an externally stored list, implementations SHOULD enforce limits 404 on the number of recipients and/or on domains to which such 405 recipients belong. 407 Note in particular that it can be too easy for a script to use 408 redirect :list "ab:default"; 409 to send messages to "everyone in your address book", and one can 410 easily imagine both intentional and accidental abuse. The situation 411 can be even worse for, say, "ab:corporate". Warnings, as well as 412 enforced limits, are appropriate here. 414 4. IANA Considerations 415 4.1. Registration of Sieve Extension 417 The following template specifies the IANA registration of the Sieve 418 extension specified in this document. This information should be 419 added to the list of sieve extensions given on 420 http://www.iana.org/assignments/sieve-extensions. 422 To: iana@iana.org 424 Subject: Registration of new Sieve extension 426 Capability name: extlists 428 Description: Adds the ":list" match type to certain Sieve tests, and 429 the ":list" argument to the "redirect" action. The ":list" match 430 type changes tests to match values against values stored in one 431 or more externally stored lists. The ":list" argument to the 432 redirect action changes the redirect action to forward the 433 message to email addresses stored in the externally stored list. 435 RFC number: this RFC 437 Contact address: Sieve mailing list 439 4.2. Registration of ManageSieve Capability 441 The following requests IANA to register a new ManageSieve Capability 442 according to the IANA registration template specified in [RFC5804]: 444 To: iana@iana.org 446 Subject: ManageSieve Capability Registration 448 Capability name: extlists 450 Description: This capability is returned if the server supports the 451 "extlists" [RFCXXXX] Sieve extension. 453 Relevant publications: this RFC, Section 2.7 455 Person & email address to contact for further information: Sieve 456 mailing list 458 Author/Change controller: IESG 460 4.3. Registration of "ab" URI Scheme 462 The following requests IANA to register a new URI scheme according to 463 the IANA registration template specified in [RFC4395]: 465 URI scheme name: ab 467 Status: Permanent 469 URI scheme syntax: 470 paburi = "ab:" addrbook [ "?" extensions ] 471 addrbook = segment 472 ; defined in [RFC3986] 473 extensions = query 474 ; defined in [RFC3986] 476 URI scheme semantics: "ab" URIs are used for designating references 477 to address books. An address book is an internal concept used by 478 different applications (such as Sieve interpreters) for 479 describing a list of named entries, and may be translated into 480 other types of address books, such as LDAP Groups. Address books 481 may be private or shared; they may be personal, organizational, 482 or perhaps even "crowdsourced". 484 Encoding considerations: Percent-encoding is allowed in "segment" 485 and "query" components. Internationalization is handled by IRI 486 processing. 488 Intended usage: An "ab" URI is designed to be used internally by 489 applications for referencing address books. Each URI is intended 490 to represent a grouping of addresses that can be logically 491 thought of as one "book". Any given address can belong to more 492 than one book -- that is, can be referred to by more than one 493 URI. 495 The URI "ab:default" is a reserved name that MUST be implemented, 496 representing a default grouping (book) of addresses. Other 497 names, representing the same or other groupings MAY be 498 implemented. For example, an implementation might have the 499 following URIs: 501 * ab:personal -- a book representing the user's personal 502 address book. 504 * ab:friends -- a subset of ab:personal, defined by the user. 506 * ab:family -- a subset of ab:personal, defined by the user. 508 * ab:company -- a book representing user's company's address 509 book. 511 * ab:department -- a subset of ab:company, defined by the 512 company. 514 * ab:co-workers -- a subset of ab:company, defined by the user. 516 * ab:default -- the default address book, a reference to ab: 517 personal. 519 Applications and/or protocols that use this URI scheme name: 520 Currently only the Sieve External List extension is using this 521 URI scheme. Email clients that use URIs internally might find 522 this URI scheme to be useful as well. 524 Interoperability considerations: Applications are only REQUIRED to 525 support "ab:default". 527 Security considerations: Applications SHOULD ensure appropriate 528 restrictions are in place to protect sensitive information that 529 might be revealed by "ab" URIs from access or modification by 530 untrusted sources. 532 Relevant publications: this RFC 534 Contact: Sieve mailing list 536 Author/Change controller: IETF/IESG 538 5. Acknowledgements 540 Thanks to Alexandros Vellis, Nigel Swinson, Ned Freed, Kjetil Torgrim 541 Homme, Dave Cridland, Cyrus Daboo, Pete Resnick, and Robert Burrell 542 Donkin for ideas, comments and suggestions. Kristin Hubner also 543 helped greatly with the examples. 545 6. References 547 6.1. Normative References 549 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 550 Requirement Levels", BCP 14, RFC 2119, March 1997. 552 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 553 Resource Identifier (URI): Generic Syntax", STD 66, 554 RFC 3986, January 2005. 556 [RFC4151] Kindberg, T. and S. Hawke, "The 'tag' URI Scheme", 557 RFC 4151, October 2005. 559 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 560 Registration Procedures for New URI Schemes", BCP 35, 561 RFC 4395, February 2006. 563 [RFC5228] Guenther, P. and T. Showalter, "Sieve: An Email Filtering 564 Language", RFC 5228, January 2008. 566 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 567 Specifications: ABNF", STD 68, RFC 5234, January 2008. 569 [RFC5804] Melnikov, A. and T. Martin, "A Protocol for Remotely 570 Managing Sieve Scripts", RFC 5804, July 2010. 572 6.2. Informative References 574 [I-D.ietf-vcarddav-carddav] 575 Daboo, C., "vCard Extensions to WebDAV (CardDAV)", 576 draft-ietf-vcarddav-carddav-10 (work in progress), 577 November 2009. 579 [RFC2244] Newman, C. and J. Myers, "ACAP -- Application 580 Configuration Access Protocol", RFC 2244, November 1997. 582 [RFC4510] Zeilenga, K., "Lightweight Directory Access Protocol 583 (LDAP): Technical Specification Road Map", RFC 4510, 584 June 2006. 586 [RFC5229] Homme, K., "Sieve Email Filtering: Variables Extension", 587 RFC 5229, January 2008. 589 [RFC5231] Segmuller, W. and B. Leiba, "Sieve Email Filtering: 590 Relational Extension", RFC 5231, January 2008. 592 [RFC5233] Murchison, K., "Sieve Email Filtering: Subaddress 593 Extension", RFC 5233, January 2008. 595 [RFC5235] Daboo, C., "Sieve Email Filtering: Spamtest and Virustest 596 Extensions", RFC 5235, January 2008. 598 [RFC5260] Freed, N., "Sieve Email Filtering: Date and Index 599 Extensions", RFC 5260, July 2008. 601 [RFC5435] Melnikov, A., Leiba, B., Segmuller, W., and T. Martin, 602 "Sieve Email Filtering: Extension for Notifications", 603 RFC 5435, January 2009. 605 [RFC5437] Saint-Andre, P. and A. Melnikov, "Sieve Notification 606 Mechanism: Extensible Messaging and Presence Protocol 607 (XMPP)", RFC 5437, January 2009. 609 [RFC5463] Freed, N., "Sieve Email Filtering: Ihave Extension", 610 RFC 5463, March 2009. 612 Authors' Addresses 614 Alexey Melnikov 615 Isode Limited 616 5 Castle Business Village 617 36 Station Road 618 Hampton, Middlesex TW12 2BX 619 UK 621 Email: Alexey.Melnikov@isode.com 623 Barry Leiba 624 Huawei Technologies 626 Phone: +1 646 827 0648 627 Email: barryleiba@computer.org 628 URI: http://internetmessagingtechnology.org/