idnits 2.17.1 draft-fanf-dane-smtp-03.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 == Line 330 has weird spacing: '...ocument this ...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (June 6, 2012) is 4341 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) == Outdated reference: A later version (-23) exists of draft-ietf-dane-protocol-21 -- Obsolete informational reference (is this intentional?): RFC 4409 (Obsoleted by RFC 6409) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNS-Based Authentication of Named T. Finch 3 Entities (DANE) University of Cambridge 4 Internet-Draft June 6, 2012 5 Intended status: Standards Track 6 Expires: December 8, 2012 8 Secure SMTP with TLS, DNSSEC and TLSA records. 9 draft-fanf-dane-smtp-03 11 Abstract 13 SMTP has a STARTTLS extension, but (especially in the case of inter- 14 domain mail transfer) it only provides very limited security because 15 it does not specify how to authenticate the server's certificate. 16 This memo specifies how TLSA records in the DNS can be used for 17 proper SMTP server authentication. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on December 8, 2012. 36 Copyright Notice 38 Copyright (c) 2012 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3. Inter-domain SMTP with TLSA . . . . . . . . . . . . . . . . . 4 56 3.1. MX lookup checks . . . . . . . . . . . . . . . . . . . . . 4 57 3.2. SMTP server checks . . . . . . . . . . . . . . . . . . . . 5 58 4. Intra-domain SMTP with TLSA . . . . . . . . . . . . . . . . . 6 59 5. The Transmitted: header field . . . . . . . . . . . . . . . . 6 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 61 6.1. "with" protocol types . . . . . . . . . . . . . . . . . . 7 62 6.2. Permanent message header field registration . . . . . . . 8 63 6.3. "dane" MTA-name-type . . . . . . . . . . . . . . . . . . . 8 64 7. Security considerations . . . . . . . . . . . . . . . . . . . 8 65 7.1. Fallback to insecure SMTP . . . . . . . . . . . . . . . . 8 66 7.2. A mail domain trusts its SMTP servers . . . . . . . . . . 9 67 7.3. Temporary failures and denial of service . . . . . . . . . 9 68 7.4. Deliberate omissions . . . . . . . . . . . . . . . . . . . 9 69 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 70 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 72 9.2. Informative References . . . . . . . . . . . . . . . . . . 11 73 Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . . 11 74 Appendix B. Rationale - choice of certificate identity . . . . . 12 75 Appendix C. Change log . . . . . . . . . . . . . . . . . . . . . 13 76 C.1. Changes in version -03 . . . . . . . . . . . . . . . . . . 13 77 C.2. Changes in version -02 . . . . . . . . . . . . . . . . . . 13 78 C.3. Changes in version -01 . . . . . . . . . . . . . . . . . . 13 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 81 1. Introduction 83 The specification for SMTP over TLS [RFC3207] does not describe how 84 to authenticate a server: which identity relating to the connection 85 ought to be authenticated by the server's certificate. In practice, 86 most certificates presented by publicly-referenced SMTP servers 87 either cannot be validated with respect to a well-known certification 88 authority, or do not verify any identity expected by the client. 90 As a result, inter-domain SMTP clients cannot require working server 91 authentication if they want to successfully send mail using TLS. 92 Therefore TLS currently provides only a limited amount of additional 93 security for inter-domain SMTP. Its encryption protects against on- 94 path passive eavesdropping; but it does not protect against an active 95 attack, since the client has no way to detect when an attacker is 96 spoofing the server. 98 This memo describes how to fix this using DNSSEC [RFC4033] and TLSA 99 records [I-D.ietf-dane-protocol] with owner names of the form 100 "_25._tcp.hostname". 102 We use DNSSEC to secure the association between a mail domain and its 103 SMTP server host names, and between the host names and their 104 certificates. Connections to servers are authenticated by their TLS 105 certificates. 107 As well as its normal function of providing an association between a 108 domain name and a certificate, we are also using the existance of a 109 TLSA record to signal to the client that it can expect the server to 110 offer TLS with a valid certificate. 112 The security situation is better for intra-domain SMTP, because in 113 this case the client and server can be configured with prior 114 knowledge of how to authenticate each other. This specification can 115 also be used for authenticating servers in intra-domain SMTP. 117 This memo does not cover message submission [RFC4409] [RFC5068] 118 [RFC6186], nor does it cover LMTP [RFC2033], since they use the DNS 119 in a different way than MTA-to-MTA SMTP. 121 The protocol described in this memo adds new security checks that can 122 cause email delivery to be delayed when a security failure is 123 detected. We specify that clients treat a problems as a "temporary 124 failure", causing the message to be queued for a later delivery 125 attempt, in the hope that the attack (or configuration error) will 126 have been dealt with. 128 2. Terminology 130 ADMD: An ADministrative Management Domain, as described in the 131 Internet Mail Architecture [RFC5598]. 133 Inter-domain SMTP: SMTP between different ADMDs across the public 134 Internet, where a client MTA sends mail to a publicly-referenced 135 SMTP server MTA. 137 Intra-domain SMTP: SMTP between MTAs within an ADMD. 139 Mail domain: The part of an email address after the "@"; also the 140 owner name of a (possibly implicit) MX record. 142 MX resolution: The algorithm for resolving a mail domain into a set 143 of SMTP server hosts, described in [RFC5321] section 5. 145 Publicly-referenced SMTP server: An SMTP server which runs on port 146 25 of an Internet host located using MX resolution. (This term is 147 from [RFC3207].) 149 SMTP server host name: The target of a (possibly implicit) MX 150 record. 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 154 memo are to be interpreted as described in [RFC2119]. 156 3. Inter-domain SMTP with TLSA 158 In the following we describe some additions to the usual MX 159 resolution algorithm described in [RFC5321] section 5. If there is 160 any conflict between this memo and the other specifications cited in 161 this section, that is an error in this memo. 163 3.1. MX lookup checks 165 The client SHALL look up the MX RRset for the mail domain. There are 166 three succesful results that yield a list of SMTP server host names: 168 o A list of one or more MX records; 170 o An implicit MX record, in lieu of an empty list of MX records; 172 o A CNAME or DNAME pointing to a successful result. 174 If the lookup is not successful, the client SHALL proceed as 175 described in [RFC5321] section 5. 177 If any of the responses is "bogus" according to DNSSEC validation 178 ([RFC4033] section 5) the client MUST treat this as a temporary 179 error. 181 For this protocol to take effect, all of these DNS RRsets MUST be 182 "secure" according to DNSSSEC validation. In the case of an implicit 183 MX record, there MUST be a secure denial of existence of an MX RRset 184 for the mail domain. In the case of a (chain of) CNAME or DNAME RRs, 185 the whole chain MUST be secure as well as the ultimate target. 187 If they are not all secure, this protocol has not been fully 188 deployed. The client SHOULD fall back to insecure delivery (which 189 might be over unauthenticated TLS). 191 The client now has an authentic list of SMTP server host names and 192 priority values. It processes this list as described in [RFC5321] 193 section 5 (sorting the host names etc.) without regard to the 194 presence or absence of DNSSEC or TLSA records. 196 3.2. SMTP server checks 198 This sub-section applies to each SMTP server host name individually. 200 When connecting to a server, the client SHALL look up the server's 201 TLSA RRset as described in [I-D.ietf-dane-protocol] section 3. That 202 is, the TLSA RRset owner name SHALL be "_25._tcp.hostname" where 203 "hostname" is the SMTP server host name. The response can be one of 204 the following (as listed in [I-D.ietf-dane-protocol] section 4.1): 206 o A secure answer containing one or more TLSA records, in which case 207 the client SHALL proceed as descrbed below. 209 o A bogus answer or other failure, which the client MUST treat as a 210 temporary error. 212 o If there is no TLSA record or its DNSSEC validation state is 213 insecure or indeterminate, this protocol has not been fully 214 deployed. The client SHOULD deliver to this server insecurely 215 (which might be over unauthenticated TLS). 217 The client now has one or more TLSA records for the server it is 218 connecting to. 220 The client MUST ensure that the server offers the STARTTLS service 221 extension [RFC3207] in its response to the client's EHLO command 222 ([RFC5321] section 4.1.1.1). 224 The client SHALL then issue the STARTTLS command which MUST be 225 successful. It then proceeds with TLS negotiation [RFC5246]. If the 226 client uses the Server Name Indication TLS extension ([RFC6066] 227 section 3) it MUST use the SMTP server host name as the value for the 228 ServerName field. 230 The client SHALL validate the server's certificate as described in 231 [I-D.ietf-dane-protocol] section 2.1. 233 The client SHALL verify the server's identity as described in 234 [RFC6125] section 6. Its list of reference identifiers SHOULD 235 include the SMTP server host name with type DNS-ID, and MAY include a 236 second copy of the host name with type CN-ID. 238 If any of these checks fail, the client MUST disconnect from the 239 server and treat this as a temporary failure. 241 The client can now proceed to deliver mail securely. 243 4. Intra-domain SMTP with TLSA 245 Mail transmission within an ADMD can be based on MX records (such as 246 when delivering incoming mail to its destination host) or on 247 statically configured host names (such as when routing outgoing mail 248 via a border relay). 250 When routing internal mail using MX records, Section 3 applies the 251 same as for inter-domain SMTP. 253 When routing mail using host names, the MX lookup step is skipped and 254 only Section 3.2 applies. 256 5. The Transmitted: header field 258 The client MAY wish to insert a Transmitted: header field at the 259 start of the message header just before transmitting the message. 260 This records the result of the checks specified in the previous 261 section. (See Section 7 for some comments on its utility or lack 262 thereof.) It is a client-side counterpart to the Received: header 263 field ([RFC5321] section 4.4) and has very similar syntax. It SHOULD 264 be treated as a trace field. 266 The syntax of the Transmitted: header field is described using ABNF 267 [RFC5234]. Non-terminal syntax rules not defined in this memo are 268 defined in [RFC5321], or [RFC5322], or [RFC5234]. 270 Transmitted-line = "Transmitted:" FWS To-domain By-domain 271 Opt-info [CFWS] ";" date-time CRLF 273 To-domain = "TO" FWS Extended-Domain 275 A SHALL include: 277 o A clause describing the SMTP server. The 278 part of a SHALL be the same as the SMTP server host 279 name. 281 o A clause identifying the SMTP client that added the 282 header. (If the client also acts as a server this is the same 283 clause it would include in any Received: header fields 284 it adds.) This clause helps with recovery if the original order 285 of a message header's fields has been lost. 287 o Various clauses, which MUST include a clause. 288 The part of this clause is used to indicate whether the 289 client successfully authenticated the server, using one of the 290 types specified in Section 6.1. 292 o And a to further help with disordering in case a 293 message is transmitted by the same client more than once. 295 6. IANA Considerations 297 6.1. "with" protocol types 299 The "with" protocol type registry includes a number of keywords that 300 indicate the use of SMTP with or without TLS and/or AUTH [RFC3848]. 301 When these types appear in a Transmitted: header field "with" clause 302 they indicate that the client did not authenticate the server as 303 described in Section 3. 305 o The new keyword "ESMTPT" indicates the use of ESMTP [RFC5321] with 306 STARTTLS [RFC3207] when the client successfully authenticated the 307 server. 309 o The new keyword "ESMTPTA" indicates the use of ESMTP [RFC5321] 310 with STARTTLS [RFC3207] and AUTH [RFC4954] when the client 311 successfully authenticated the server. 313 These new keywords are not for use in Received: header fields since 314 the server cannot tell whether or not the client authenticated it. 316 There are no keywords corresponding to a client trying and failing to 317 authenticate the server, since in this case no message transmission 318 occurs. 320 6.2. Permanent message header field registration 322 Header field name: Transmitted: 324 Applicable protocol: mail 326 Status: standard 328 Change controller: IETF 330 Specification document this memo 332 6.3. "dane" MTA-name-type 334 Delivery status notifications [RFC3464] can include a Remote-MTA 335 field recording an SMTP server host name. When this has been 336 authenticated according to Section 3 the reporting MTA MAY use an 337 MTA-type-name of "dane". 339 a. MTA-type-name: "dane" 341 b. Syntax: same as the "dns" MTA-type-name [RFC3461] 343 c. Translation into US-ASCII: none needed 345 7. Security considerations 347 7.1. Fallback to insecure SMTP 349 This memo provides only conditional security. It allows a server to 350 publish in the DNS the details of how it can be authenticated. 351 Clients that implement this protocol can use it to provide a strong 352 guarantee that they are sending mail to the correct place. If either 353 of these is missing, mail delivery will be insecure. 355 There is no secure way for a server to tell if a client has 356 authenticated it using this protocol. This is a general limitation 357 of TLS. The Transmitted: header field records this information for 358 tracing and debugging and measuring deployment, not for security 359 purposes. 361 We do not specify that clients check that all of a mail domain's SMTP 362 server host names consistently have or do not have TLSA records. 363 This is so that partial or incremental deployment does not break mail 364 delivery. Different levels of deployment are likely if a domain has 365 a third-party backup MX, for example. 367 The MX sorting rules are unchanged; in particular they have not been 368 altered in order to prioritize secure servers over insecure servers. 369 If a site wants to be secure it needs to deploy this protocol 370 completely; a partial deployment is not secure and we make no special 371 effort to support it. 373 7.2. A mail domain trusts its SMTP servers 375 By signing their zone with DNSSEC, a mail domain owner implicitly 376 instructs SMTP clients to check their SMTP server TLSA records. This 377 implies another point in the trust relationship between mail domain 378 owner and smtp server operator. Most of the setup requirements for 379 this protocol fall on the SMTP server operator: installing a TLS 380 certificate with the correct name, and publishing a TLSA record under 381 that name. If these are not correct then mail delivery from TLSA- 382 aware clients might be delayed. 384 7.3. Temporary failures and denial of service 386 Many provisioning failures in SMTP cause "permanent" failures, that 387 is the immediate and final rejection of the message. This includes 388 missing DNS records, an SMTP server that is not configured to accept 389 mail for the recipient domain, and so forth. 391 In this protocol, provisioning an incorrect TLS certificate triggers 392 a temporary error. This is because we want to minimise the damage 393 that occurs when an on-path attacker intercepts the TCP connection 394 between an SMTP client and server. An attacker can cause delays, but 395 is not able to trigger immediate delivery failures. 397 7.4. Deliberate omissions 399 We do not specify that clients check the DNSSEC state of the SMTP 400 server address records. This is not necessary since the certificate 401 checks ensure that the client has connected to the correct server. 402 (The address records will normally have the same security state as 403 the TLSA records, but they can differ if there are CNAME or DNAME 404 indirections.) 406 This memo does not specify any changes to SMTP client authentication. 407 Inter-domain SMTP client authentication remains extremely weak. 408 Intra-domain SMTP can be configured as strong as necessary (using 409 SMTP AUTH or TLS client certificates, for instance) but that is out 410 of scope for this memo. 412 8. Acknowledgements 414 Thanks to Mark Andrews for arguing that authenticating the SMTP 415 server host name is the right thing, and that we should rely on 416 DNSSEC to secure the MX lookup. Thanks to Ned Freed, Olafur 417 Gudmundsson, Paul Hoffman, Phil Pennock, Hector Santos, and 418 Alessandro Vesely for helpful suggestions. 420 9. References 422 9.1. Normative References 424 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 425 Requirement Levels", BCP 14, RFC 2119, March 1997. 427 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over 428 Transport Layer Security", RFC 3207, February 2002. 430 [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service 431 Extension for Delivery Status Notifications (DSNs)", 432 RFC 3461, January 2003. 434 [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format 435 for Delivery Status Notifications", RFC 3464, 436 January 2003. 438 [RFC3848] Newman, C., "ESMTP and LMTP Transmission Types 439 Registration", RFC 3848, July 2004. 441 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 442 Rose, "DNS Security Introduction and Requirements", 443 RFC 4033, March 2005. 445 [RFC4954] Siemborski, R. and A. Melnikov, "SMTP Service Extension 446 for Authentication", RFC 4954, July 2007. 448 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 449 Specifications: ABNF", STD 68, RFC 5234, January 2008. 451 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 452 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 454 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 455 October 2008. 457 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 458 October 2008. 460 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 461 Extension Definitions", RFC 6066, January 2011. 463 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 464 Verification of Domain-Based Application Service Identity 465 within Internet Public Key Infrastructure Using X.509 466 (PKIX) Certificates in the Context of Transport Layer 467 Security (TLS)", RFC 6125, March 2011. 469 [I-D.ietf-dane-protocol] 470 Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 471 of Named Entities (DANE) Transport Layer Security (TLS) 472 Protocol: TLSA", draft-ietf-dane-protocol-21 (work in 473 progress), May 2012. 475 9.2. Informative References 477 [RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033, 478 October 1996. 480 [RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", 481 RFC 4409, April 2006. 483 [RFC5068] Hutzler, C., Crocker, D., Resnick, P., Allman, E., and T. 484 Finch, "Email Submission Operations: Access and 485 Accountability Requirements", BCP 134, RFC 5068, 486 November 2007. 488 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, 489 July 2009. 491 [RFC6186] Daboo, C., "Use of SRV Records for Locating Email 492 Submission/Access Services", RFC 6186, March 2011. 494 Appendix A. Example 496 In the following, most of the DNS resource data is elided for 497 simplicity. 499 ; mail domain 500 example.com. MX 1 mx.example.net. 501 example.com. RRSIG MX ... 503 ; SMTP server host name 504 mx.example.net. A 192.0.2.1 505 mx.example.net. AAAA 2001:db8:212:8::e:1 507 ; TLSA resource record 508 _25._tcp.mx.example.net. TLSA ... 509 _25._tcp.mx.example.net. RRSIG TLSA ... 511 Mail for addresses at example.com is delivered by SMTP to 512 mx.example.net. Connections to mx.example.net port 25 that use 513 STARTTLS will get a server certificate that authenticates the name 514 mx.example.net. 516 Appendix B. Rationale - choice of certificate identity 518 There are a number of reasons for the certificate to authenticate the 519 SMTP server host name rather than the mail domain. 521 SMTP allows a client to transfer mail to recipients at multiple 522 domains in the same connection. If the certificate identifies the 523 host name then it does not need to list all the possible mail 524 domains. 526 It is not in general feasible for the server to select a mail domain 527 certificate based on the recipient domains when the connection is 528 established (using Server Name Indication, [RFC6066] section 3), 529 because an SMTP client might not know all of the recipients when it 530 establishes the connection. 532 Outgoing SMTP relays and message submission servers handle mail for 533 any domain, so in those cases the only sensible option is for the 534 certificate to contain the host name. It is more consistent for 535 incoming MX server certificates to match. 537 It is common for SMTP servers to act in multiple roles, as outgoing 538 relays or as incoming MX servers, depending on the client identity. 539 It is simpler if the server can present the same certificate 540 regardless of the role in which it is to act. 542 Sometimes the server does not know its role until the client has 543 authenticated, which usually occurs after TLS has been established. 545 This protocol does not provide an option for directly authenticating 546 the mail domain because that would add complexity without providing 547 any benefit, and security protocols are best kept simple. As 548 described above, there are real-world cases where authenticating the 549 mail domain cannot be made to work, so there are complicated criteria 550 for when mail domain TLSA records might be used and when they cannot. 551 This is all avoided by authenticating the SMTP server host name. 553 Finally, this protocol only affects the logic in the SMTP client and 554 requires no additional SMTP server functionality, such as support for 555 the TLS Server Name Indication extension. 557 Appendix C. Change log 559 C.1. Changes in version -03 561 Clarify how to use SNI with this protocol. 563 Clarify lack of changes to MX sorting rules. 565 Mention DNAME as well as CNAME. 567 An example. 569 C.2. Changes in version -02 571 Clarify the wording that describes how a client determines that this 572 protocol is in effect. 574 Divide the security considerations into sub-sections, and add a 575 subsection on denial of service. 577 Clarify intro, mentioning TLSA owner name format. 579 Extend the scope to cover MTA-to-MTA mail within an ADMD as well as 580 between ADMDs. 582 C.3. Changes in version -01 584 More about why not to authenticate mail domains in the rationale. 586 Change DNS-ID requirement from MUST to SHOULD to follow RFC 6125. 588 Acknowledgments section. 590 Transmitted: header trace field. Not sure if this is a good idea; 591 feedback wanted. 593 "dane" MTA-name-type for use in DSNs. Even less sure if this is a 594 good idea. 596 Author's Address 598 Tony Finch 599 University of Cambridge Computing Service 600 New Museums Site 601 Pembroke Street 602 Cambridge CB2 3QH 603 ENGLAND 605 Phone: +44 797 040 1426 606 Email: dot@dotat.at 607 URI: http://dotat.at/