idnits 2.17.1 draft-ietf-marid-rationale-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 3 instances of too long lines in the document, the longest one being 13 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 129 has weird spacing: '...hannels throu...' == Line 156 has weird spacing: '...ossible while...' == Line 484 has weird spacing: '... relays ident...' == Line 558 has weird spacing: '...ctation that ...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2004) is 7254 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? 'RFC2396' on line 761 looks like a reference -- Missing reference section? 'CSV' on line 768 looks like a reference -- Missing reference section? 'RMX' on line 769 looks like a reference -- Missing reference section? 'DMP' on line 770 looks like a reference -- Missing reference section? 'DVP' on line 771 looks like a reference -- Missing reference section? 'SPF' on line 772 looks like a reference -- Missing reference section? 'DRIP' on line 773 looks like a reference -- Missing reference section? 'MTAMark' on line 774 looks like a reference -- Missing reference section? 'SS' on line 775 looks like a reference -- Missing reference section? 'FSV' on line 776 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft 2 Category: Informational Meng Weng Wong, pobox.com 3 draft-ietf-marid-rationale-00.txt 4 Expires: September 2004 June 2004 6 Behind The Curtain: An Apology for Sender ID 8 Status of this Memo 10 This document is an Internet-Draft and is subject to all provisions 11 of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as 16 Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet- 21 Drafts as reference material or to cite them other than as 22 "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/1id-abstracts.html 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 This Internet-Draft will expire in September 2004. 32 Abstract 34 The architecture of Sender ID follows from a set of design 35 decisions. Those decisions were motivated by philosophical, 36 engineering, and political considerations. This document reviews 37 some of the important choice that distinguish Sender ID from 38 alternative possibilities in the same space. 40 Table of Contents 42 1. The Aspen Framework 43 2. Two Cultures Of Authentication 44 3. Architectural Considerations 45 4. Design Goals and Guidelines 46 4.1 Design Goals 47 4.1.1 Fast widespread adoption. 48 4.1.2 Minimizing friction. 49 4.2 Design Guidelines 50 4.2.1: optimize for ease of publishing over ease of implementation. 51 4.2.2: follow the path of least resistance. 52 4.2.3: Find a middle way by setting mechanism, not policy. 53 5. Life Cycle Design 54 6. Choices reflected in Sender ID's Architecture 55 6.1. Identity 56 6.1.1. Am I MTA or Not? 57 6.1.2. Am I an MTA for the HELO domain? 58 6.1.3. Am I an MTA for the MAIL FROM domain? 59 6.1.4. Am I an MTA for the responsible sender according to the 2822 headers? 60 6.1.5. Why use SUBMITTER instead of the HELO name? 61 6.2. Per User Lookups 62 6.3. Response Codes 63 6.4. Block or Factored 64 6.5. Set-theoretic or Procedural 65 6.6. Record Type 66 6.7. Record Syntax 67 7. Business Analyses 68 7.1. Economic Analysis: Market failure and collective action 69 7.2. Marketing Analysis: Chasm Theory 70 7.3. The need for coordinated deployment. 71 Normative References 72 Informative References 73 Author 75 ---------------------------------------------------------------------- 76 1. The Aspen Framework 77 ---------------------------------------------------------------------- 79 Sender ID fits into a larger framework which was devised at a 80 conference held at the Aspen Institute in December 2003. That 81 framework has these parts: 83 1) authentication 84 2) accreditation 85 3) reputation 87 Authentication tries to answer the question: "How confident can a 88 receiver be that an email message really is from who it claims to be 89 from?" It counters forgery and fraud. 91 Accreditation lets third parties vouch for senders with whom they have 92 a prior relationship. 94 Reputation systems help receivers decide the disposition of incoming 95 messages. Reputation systems rate senders and their accreditors. 97 Receivers may develop local reputation systems, employ third party 98 reputation services, trust certain accreditors directly, or do all of 99 the above. 101 The absence of prior trust between arbitrary senders and receivers 102 implies a potentially skeptical relationship between accreditation and 103 reputation services. 105 This framework resonates with real-world models of human interaction. 106 For example, reputation services exist today in the form of credit 107 bureaus and movie reviews. Accreditation services exist today in the 108 form of passports and university diplomas. 110 Sender ID directly enables authentication and accreditation, and 111 indirectly supports reputation technologies. 113 ---------------------------------------------------------------------- 114 2. Two Cultures Of Authentication 115 ---------------------------------------------------------------------- 117 Sender ID provides syntax and semantics that help answer the 118 authentication question: "How confident can a receiver be that an 119 email message really is from who it claims to be from?" But there are 120 at least two ways to ask and answer the question. 122 In a designated sender scheme, the question becomes: "is the SMTP 123 client of an incoming message authorized by the purported sender of 124 that message to send the message?" The primary identity is the sender 125 of the message --- the (administratively independent) entity 126 responsible for the most recent injection of the message into the 127 mailstream. 129 Designated sender schemes consider the channels through which a 130 message is transported. They do not consider the content of the 131 message. In a store-and-forward model of email, designated sender 132 schemes apply to hops between administratively independent domains. 134 In a cryptographic scheme, the question becomes: "do the credentials 135 embedded in the message validate its purported authorship, according to 136 a public-key cryptosystem?" The primary identity is the author of the 137 message --- the entity which created the content. 139 Cryptographic schemes consider the content of a message. They do not 140 consider the means by which it was delivered. Cryptographic schemes 141 are congruent with an end-to-end model of email. 143 Note that designated sender schemes are generally better suited to 144 identifying senders and cryptographic schemes are better suited to 145 identifying authorsship. 147 Sender ID defines mechanisms that implement a designated sender scheme. 148 Sender ID can also be extended to describe cryptographic schemes. 150 ---------------------------------------------------------------------- 151 3. Architectural Considerations 152 ---------------------------------------------------------------------- 154 The greatest virtue of Internet email is openness. Open systems suffer 155 the problem of abuse. Sender ID tries to curtail domain spoofing as 156 much as possible while encroaching upon virtues as little as 157 possible. It does this by aiming for mechanism, not policy. 159 A number of competing requirements inform the design. On the one hand, 160 position A is valid; on the other, so is position B. 162 - Zombies versus hobbyists. 163 - Spam folders versus SMTP rejects. 164 - Rejecting before DATA vs rejecting after DATA. 165 - 100% backward compatibility versus an unacceptable status quo. 166 - Nipping the innocent in the bud. 167 - Inconveniencing non-participants. 168 - The perfect is the enemy of the good. 169 - There is no such thing as an interim standard. 170 - This is a job for sysadmins. 171 - DNS: Caching versus parsing. 172 - DNS: speed vs expressiveness. 173 - DNS: ease of writing vs ease of reading. 174 - DNS: use of XML vs development of a little language. 176 Zombies versus hobbyists: 178 A - A majority of spam today originates from end-user machines 179 infected by viruses that send spam directly to receivers' MX 180 servers. Such zombies should no longer be able to send 181 direct-to-mx spam. 183 B - Linux hobbyists should still be able to send mail from their 184 consumer-grade broadband connections. They may have no control 185 over the PTR records of their assigned IP addresses, but the 186 concept of first-class and second-class citizenship rankles many 187 idealists who believe in an unfettered end-to-end model of pure 188 IP connectivity. 190 Spam folders versus SMTP rejects: 192 A - Rejecting messages at SMTP time is too abrupt. Filing to a 193 spam folder is better; that way, recipients have a chance to pull 194 false positives back from the brink without embarrassment. 196 B - Filing to a spam folder often means nobody sees a message, and 197 false positives silently disappear. If a sender receives no 198 notification that a message was lost, the integrity of the email 199 system suffers. 201 Rejecting before DATA vs rejecting after DATA. 203 A - If the protocol makes spoofs rejectable before DATA, we save 204 bandwidth. We can even honour per-user policies. 206 B - If the protocol rejects spoofs only after the message DATA has 207 been received, we have the opportunity to review the message 208 content in greater detail. 210 100% backward compatibility versus an unacceptable status quo: 212 A - the Old Email is broken in many ways, and spam will continue to 213 be a problem until it is fixed. 215 B - the New Email should be 100% backward compatible with the Old 216 Email, and nobody should have to change anything for the New 217 Email to work. 219 Nipping the innocent in the bud: 221 A - Spam should be stopped before it starts; to limit the cost of a 222 spam attack, receivers should by default adopt a skeptical stance 223 to any unknown input. In big cities, people don't talk to 224 strangers. 226 B - In small towns, people smile at strangers. Senders should be 227 assumed innocent until proven guilty. Any person should be able 228 to get onto the Internet, register a domain, and immediately 229 email a hundred of his closest friends. 231 Inconveniencing non-participants: 233 A - The designated sender model works correctly for the vast majority 234 of all mail, which is sent directly from sender to recipient. In 235 its strong form, Sender ID permits rejection of unwanted mail 236 before the DATA command; this represents a significant bandwidth 237 savings. 239 Under the designated sender model, the strategy that minimizes 240 the global amount of work requires non-conformant sites 241 (primarily, forwarders and web-generated emailers) to work toward 242 conformance (ie. Pre-pending headers and adding SUBMITTER 243 support 245 B - Forwarders and web-generated emailers are merely operating 246 according to time-honoured traditions. Sender ID changes the 247 terms of their unwritten contract; it is unfair to demand that 248 they change. Placing the good of the many above the good of the 249 few can lead to a tyranny of the majority. 251 The perfect is the enemy of the good: 253 A - people who are losing money every day due to spam want the New 254 Email to be done quickly. 256 B - people who worry about the overall architectural integrity of the 257 Internet want the New Email to be done right, even if that takes 258 longer. 260 There is no such thing as an interim standard: 262 A - it is important to experiment with new protocols on a large scale 263 before officially blessing anything. 265 B - there is no such thing as an "interim" standard: anything that 266 rolls out at all will be there forever. 268 Perhaps this conflict can be solved by moving to a "controlled 269 burn" model of change management on the Internet. 271 This is a job for sysadmins: 273 A - the New Email should be fully transparent to the end-user and 274 require no reconfiguration. 276 B - no disagreement! 278 DNS: Caching versus parsing. 280 A - To reduce the burden on clients, records should be easily cached. 281 Records that describe the full set of designated senders up front 282 are easily cached and require no subsequent lookups. However, 283 such records require parsing. 285 B - To reduce the burden on clients, records should require minimal 286 parsing. Records that answer "yes/no" for a given query aganst a 287 domain/IP tuple can be easily parsed using existing DNSBL logic. 288 However, such records are not easily cached, particularly when a 289 wide range of IP addresses produce multiple negative results. 291 DNS: speed vs expressiveness. 293 A - The protocol should minimize the number of DNS queries needed, 294 particularly serial queries. This reduces start-to-finish time. 296 B - The protocol should be rich and expressive, even if that means 297 multiple lookups are needed to resolve an answer. This increases 298 start-to-finish time. 300 DNS: ease of writing vs ease of reading 302 A - it should be easy for senders to publish records. Maybe senders 303 should describe their designated sender policies in a high-level 304 form and leave correct interpretation up to the receivers. If 305 they change an MX server's IP address, Sender ID should be smart 306 enough to do the right thing automatically. The whole point of 307 the DNS is to map symbolic names to lower-level data. 308 Unnecessary redundancy is undesirable. 310 B - It should be easy for receivers to query records. Maybe senders 311 should be expected to precompile designated sender information 312 into a canonical form. Every time an MX server changes its IP 313 address, it's the sender's job to remember to republish the 314 designated sender data. 316 DNS: use of XML vs development of a little language 318 A - The syntax should be easy for receivers to implement. The 319 adoption of existing data formats such as XML means that existing 320 libraries can be used to parse the data. XML is popular among 321 the Microsoft community. 323 B - The syntax should be easy for receivers to implement. The use of 324 a custom-made little language means that heavyweight XML 325 libraries are not required. XML is generally unpopular among the 326 open community. 328 ---------------------------------------------------------------------- 329 4. Design Goals and Guidelines 330 ---------------------------------------------------------------------- 332 This section discusses a way to broadly measure the success of the 333 project. It also lays out the design philosophy which guides 334 decision-making. 336 * Market-based metrics. 338 Sender ID is not the only specification to take aim at the problem of 339 authentication. Other designs reflect different goals. Some designs 340 are within the LMAP family (eg. DMP, RMX). Other designs are not 341 (Call-Back Verification, Challenge/Response). 343 With a variety of designs on the market, the success of this effort can 344 be measured by relative market share; how many domains publish Sender 345 ID records, and how many receivers check them? 347 * The Fax Effect 349 The value to a domain of adopting the standard depends, in part, on the 350 number of other domains who have already adopted the standard. 352 This is commonly called the fax effect: the first two people to buy a 353 fax machine could only use it to communicate with each other, but every 354 subsequent adopter could use it to communicate with everybody else who 355 already had one. Today, faxes are everywhere. 357 Sender ID represents a major shift in the paradigm of email. For the 358 fax effect to fully manifest, a significant majority of legitimate 359 email on the Internet should be covered by Sender ID. 361 4.1 Design Goals 363 The design goals follow logically. 365 4.1.1 Fast widespread adoption. 367 To get the fax effect on our side quickly, we want to make it possible 368 for people to quickly and easily adopt the standard. 370 On the publishing end, this meant that the syntax and semantics must be 371 easily learned by busy people whose level of DNS technological savvy we 372 could not take for granted. Alternatively, a wizard can help them set 373 up records which they can treat as opaque. 375 On the receiving end, this meant that the standard should be reasonably 376 straightforward to implement for the most popular MTAs. 378 There are many more sender domains than receiving MTA implementors. 379 Therefore, the design should optimize for ease of publishing over ease 380 of implementation. 382 4.1.2 Minimizing friction. 384 Even the least amount of friction will impede adoption. The Design 385 should take advantage of existing capabilities wherever possible. The 386 design should optimize for the path of least resistance. The less 387 overhead needed to publish a record, the better. 389 4.2 Design Guidelines 391 The design guidelines that result from the above goals are: 393 4.2.1: optimize for ease of publishing over ease of implementation. 395 4.2.2: follow the path of least resistance. 397 4.2.3: Find a middle way by setting mechanism, not policy. 399 Where design alternatives appear to conflict, find a 400 technical compromise that lets each school operate; do 401 not mandate or prohibit any of the choices. 403 ---------------------------------------------------------------------- 404 5. Life Cycle Design 405 ---------------------------------------------------------------------- 407 The designed protocol is a thing that does not stand in isolation, but 408 moves through a life cycle; to be successful, it must be pass both 409 economic and marketing muster at each stage in its life. 411 Cautious people will want to transition gradually toward full 412 acceptance of Sender ID. Therefore Sender ID cannot be designed with 413 only on/off states; it should have a transitional adoption strategy. 415 Over-specifying the protocol leads to untimely ossification. 416 Under-specifying the protocol leads to a lack of expressiveness. 417 The solution to both over-specification and under-specification is to 418 ensure extensibility. Extensibility should be well defined on both 419 syntactic and semantic levels. 421 A well-designed protocol often finds itself being legitimately used in 422 ways the original designers did not anticipate. Unexpected uses 423 validate the expression model. To date, a number of unexpected uses 424 have arisen: for example, use of the "exists" mechanism to perform 425 basic logging. 427 ---------------------------------------------------------------------- 428 6. Choices reflected in Sender ID's Architecture 429 ---------------------------------------------------------------------- 431 Given the above architectural considerations, design goals, and 432 design guidelines, Sender ID makes a number of choices. 434 ---------------------------------------------------------------------- 435 6.1. Identity 436 ---------------------------------------------------------------------- 438 Authentication schemes can focus on a number of identities. 440 The simplest schemes ask if the IP address of the SMTP client should be 441 permitted to send mail or not. 443 More complex designated sender schemes add a domain-name dimension. 444 They ask if the IP address is permitted to send mail *for that domain*. 446 6.1.1. Am I MTA or Not? 448 The simplest scheme asks a network owner if a given IP address is 449 allowed to send mail to the public Internet. Instances of this scheme 450 include: 452 - .mxout. 453 - MTAMark 454 - Selective Sender 456 Such schemes generally store the permission information in the PTR 457 tree, alongside it, or in a parallel domain tree. 459 These schemes make the "zombies versus hobbyists" tradeoff in favour of 460 blocking zombies. If we assume that a hobbyist has no control over 461 their PTR record, and will have no control over their 462 MTAMark/SS/.mxout. record either, these schemes disenfranchise 463 hobbyists. 465 In accordance with its "mechanism, not policy" design philosophy, 466 Sender ID makes the "zombies versus hobbyists" tradeoff in favour of 467 hobbyists who are assumed to control the forward DNS of a domain they 468 own. The important thing is to establish accountability: if a spammer 469 wishes to designate a zombie as a permitted sender, the message is 470 Sender ID conformant; it is the responsibility of the reputation system 471 to reject the message. 473 6.1.2. Am I an MTA for the HELO domain? 475 The next simplest scheme asks the domain of the HELO command if the IP 476 address is a permitted sender for that domain. 478 - DRIP 479 - CSV 481 Authenticating the HELO identity is useful for whitelisting by MTA 482 hostname. 484 Reputation services could evaluate relays identified in the HELO 485 domain. 487 6.1.3. Am I an MTA for the MAIL FROM domain? 489 Schemes that ask this question include: 491 - DMP 492 - RMX 493 - FSV 494 - DVP 495 - SPF 497 DMP allows the HELO domain to override the MAIL FROM. 499 SPF uses the HELO domain only when the MAIL FROM is null. 501 Using the MAIL FROM address is considered useful for fighting joe-job 502 bounce blowback, but it has the disadvantage of requiring forwarders to 503 use some sort of return-path rewriting scheme and thereby become 504 transport remailers. Paul Vixie alluded to this in his 2002 paper. 506 6.1.4. Am I an MTA for the responsible sender according to the 2822 headers? 508 It is useful to use Designated Sender techniques to validate sender 509 information seen in the MUA. If conforming mailers prepend an 510 appropriate header to indicate a relay hop, MUAs can extract a 511 Purported Responsible Address (PRA) from the headers and display that 512 information. 514 The SUBMITTER parameter to MAIL FROM is a preview of the Purported 515 Responsible Address from the 2822 headers. 517 If present, it overrides MAIL FROM. 519 Using 2822 sender information is considered useful for fighting 520 phishing. 522 However, it requires that MUAs display both author and sender 523 information. Outlook already does this, with "from X on behalf of Y". 524 Other MUAs who wanted to use the benefits of 2822 Sender ID 525 authentication would have to also display "from X via Y" information. 527 If a message was forwarded through multiple hops, it may be necessary 528 to display "from X via Y via Z". 530 In the simple legitimate case, the Purported Responsible Address would 531 be the "From" header, and there would be no "Sender" or "Resent-From" 532 type headers. MUAs might be able to mark mail from certain domains 533 with a "trusted" hint. In a phishing attempt, spoofs would lack the 534 "trusted" hint. The "trusted" hint would also be missing in a message 535 sent through a forwarding system, but presumably the end-user would 536 know what messages were forwarded, and adjust their expectations 537 accordingly. 539 6.1.5. Why use SUBMITTER instead of the HELO name? 541 Promoting the Purported Responsible Address into the MAIL command 542 provides two benefits: it makes it possible to reject spoofs before 543 DATA, and it potentially makes adoption easier for forwarders. 545 The HELO name may still be authenticated using an SPF check; however, 546 it is not the subject of this document. 548 ---------------------------------------------------------------------- 549 6.2. Per User Lookups 550 ---------------------------------------------------------------------- 552 Doing per-user lookups reduces cacheability but increases granularity. 554 Per-user lookups can be supported all of the time, some of the time, or 555 none of the time. 557 Sender ID chooses to support per-user lookups some of the time using 558 the "exists" mechanism, with the expectation that only low volume 559 senders will use this feature; therefore the burden on DNS is believed 560 to be acceptable. 562 ---------------------------------------------------------------------- 563 6.3. Response Codes 564 ---------------------------------------------------------------------- 566 The simplest scheme has only two response codes: good or bad. 568 More complex schemes expand the set of responses to good, bad, and 569 unknown. 571 In response to criticism from Steve Bellovin , Sender ID provides a 572 range of seven response codes. 574 "Error" and "Unknown" correspond to temporary and permanent failures. 576 "Neutral" indicates the queried domain explicitly wishes to pretend 577 it does not publish Sender ID records. 579 "None" indicates the queried domain does not, in fact, publish 580 Sender ID records. 582 "Pass" means the administrator of the sender's domain states that the 583 message comes from an IP address assigned to one of that domain's 584 authorized outbound e-mail servers. 586 "Fail" means the administrator of the sender's domain states that the 587 IP address from which the message was received is not assigned to one 588 of that domain's authorized outbound e-mail servers. 590 "Softfail" indicates a transitional state: while not as strong as 591 "fail", it means the administrator of the sender's domain states 592 that the IP address from which the message was received is not 593 assigned to one of that domain's authorized outbound e-mail servers, 594 however, the message may still be legitimate. Receivers should 595 treat it with skepticism. This has significance for spam scoring 596 systems. The adoption path is greatly smoothed by the presence of 597 "softfail" as a standard result code. 599 ---------------------------------------------------------------------- 600 6.4. Block or Factored 601 ---------------------------------------------------------------------- 603 In a purely block-style protocol, published records completely describe 604 the sets of designated senders. Receivers are expected to figure 605 everything out based on those records. Receivers only need to fetch 606 information from senders the first time a query occurs; subsequent 607 fetches can be retrieved from the DNS resolver cache or from a nearer 608 application cache. 610 In a purely factored-style protocol, receivers include pertinent 611 information in the DNS query; sender servers are expected to return a 612 response based on those inputs. While the parsing burden tends to be 613 lower with factored-style protocols, receivers need to perform a DNS 614 lookup for each new IP client for that domain. 616 Large receiving sites tend to prefer the block style because it avoids 617 repeated lookups; for efficiency they can also transform the block 618 records into an internal representation that is locally cached and 619 distributed. 621 Specifications which use purely factored-style records are not 622 transformable. They include MTAMark, SS, DVP, and DMP. 624 Specifications which use purely block-style records are fully 625 transformable. They include Caller-ID and RMX. 627 FSV offers both block and factored record styles. 629 Sender ID is largely a block-style protocol but provides for factored 630 lookups using the "exists" mechanism. Sender ID is therefore partly 631 transformable. Publishing domains which refrain from using "ptr", 632 "exists", and per-user macros can be cached. Most high-volume senders 633 are expected to publish data in IP-only notation as a courtesy to 634 receivers. Noncacheable mechanisms are therefore expected to be used 635 only by smaller sites. This is considered an acceptable tradeoff. 637 ---------------------------------------------------------------------- 638 6.5. Set-theoretic or Procedural 639 ---------------------------------------------------------------------- 641 Block-style declarations can be further expressed in two ways: 642 set-theoretic or procedural. 644 In a set-theoretic scheme, publishers explicitly partition the input 645 space into result codes. Receivers locate the input tuple in that 646 space and return the result. 648 In a procedural scheme, publishers provide an ordered list of 649 mechanisms which are evaluated sequentially. The first mechanism to 650 match determines the result. 652 With the exception of the "exists" mechanism, the procedural scheme can 653 be mapped to a set-theoretic representation. The two schemes are 654 therefore isomorphic except when "exists" is used. 656 ---------------------------------------------------------------------- 657 6.6. Record Type 658 ---------------------------------------------------------------------- 660 Several alternatives are possible: 662 * new, custom RR type. 663 * TXT record. 664 * record with underscore subdomain. 666 The record type is still being decided. 668 ---------------------------------------------------------------------- 669 6.7. Record Syntax 670 ---------------------------------------------------------------------- 672 Two alternatives include: 674 * Ad-hoc SPF notation 675 * XML 677 Receiver systems should not have trouble supporting both using a "two 678 parsers, one interpreter" model. The ad-hoc SPF notation has been 679 specified and field-tested, and is not expected to change. The XML 680 representation is presented in the marid-core document. Sender ID 681 will be compatible with both. 683 ---------------------------------------------------------------------- 684 7. Business Analyses 685 ---------------------------------------------------------------------- 687 Where deployment and adoption are concerned, business and marketing 688 considerations are as important as technical considerations. 690 7.1. Economic Analysis: Market failure and collective action 692 To successfully deploy, the New Email requires significant resource 693 allocation: at the minimum, it needs implementation labour, 694 interoperability testing, and a big, expensive, PR campaign. Given 695 the amount of work that needs to be done, a single organization is 696 unlikely to create a pure public good at its own expense. On the 697 multinational Internet, this is as true when the organization is a 698 corporation as when the organization is a state. The technical name 699 for this problem "market failure", though it encompasses the absence 700 of government provision as well. 702 Intellectual property rights over the developed standard are one way 703 out of the market failure problem. However, the public's distaste for 704 kingmaking reduces the chances of successful adoption of any licensed 705 technology. 707 Economically speaking, market failure in this case is solved by 708 collective action by major ISPs. A mechanism that reduces the existing 709 cost of imperfect spam filtering will be adopted and evangelized by 710 ISPs who bear that cost. 712 7.2. Marketing Analysis: Chasm Theory 714 The designed product, and the augmentations that surround it, must 715 survive each phase of Geoffrey Moore's Chasm model. 717 The core specification should be attractive enough to the visionaries 718 to seed the fax effect by publishing records and writing libraries. 720 After an initial round of discovery and experimentation by the early 721 adopters, the mainstream must be encouraged to start publishing 722 records. This is the first chasm, on the publishing side. They need 723 the assurance that publishing records will, first, do no harm. 725 The beachhead for crossing the publishing-side chasm turned out to be 726 industry leaders. When enough well known domains published records, 727 they seeded the second round of the fax effect. The second round turns 728 potential receiver-side implementors into actual implementors: 729 the early adopters here are the makers of antispam email appliances and 730 edge MTAs such as CipherTrust, IronPort, Postini, and Brightmail. 731 They are ideally positioned to implement Sender ID checking on inbound 732 mail and have a business reason to do so. 734 The second chasm, on the receiving side, requires major ISPs to start 735 implementing inbound checking. Their initial motivation is to reduce 736 the costs of whitelisting. Major ISPs negotiate email peering 737 relationships with major senders and maintain, often by hand, 738 whitelists of IP addresses. Conversion to Sender ID-based whitelisting 739 is an obvious step. Note that while Sender ID is often viewed as an 740 anti-forgery mechanism, using it as a whitelisting mechanism is simply 741 the other side of the coin. 743 After these chasms are crossed, there remains the challenge of getting 744 publishers to transition through increasing levels of severity: from 745 "?" to "~" to "-". This effort requires cooperation from receivers. 747 7.3. The need for coordinated deployment. 749 The chicken-and-egg problem is this: until forwarders are Sender ID 750 compliant, publishing domains will be reluctant to advance their 751 defaults from "neutral" to "softfail" to "fail". Until publishing 752 domains have a default of "fail", forwarders may see no reason to 753 comply. 755 This problem can be overcome if industry can collectively agree on a 756 deployment schedule that gives all parties enough notice to make the 757 necessary changes. 759 Normative References 761 [RFC2396] 763 Informative References 765 Other documents in the Sender ID family. 766 Other MARID works in progress. 768 [CSV] 769 [RMX] 770 [DMP] 771 [DVP] 772 [SPF] 773 [DRIP] 774 [MTAMark] 775 [SS] 776 [FSV] 777 [etc] 779 Moore, Geoffrey. Crossing the Chasm. 781 Moore, Geoffrey. Inside the Tornado. 783 de Bono, Edward. Conflict. 785 Alexander, Christopher. A Timeless Way of Building. 787 Fisher & Ury. Getting to Yes. 789 Author 791 Meng Weng Wong 792 Singapore 793 mengwong+spf@pobox.com 795 This document is also available online at 796 http://spf.pobox.com/draft-ietf-marid-rationale-00.txt 798 Comments on this draft are welcome. 800 The appropriate forum for discussion is the MARID Working Group's 801 MXCOMP mailing list at http://www.imc.org/ietf-mxcomp/index.html