Internet Draft A. DeKok Expiration: October 22, 2004 IDT, Inc. Working Group: ASRG April 22, 2004 Lightweight MTA Authentication Protocol (LMAP) Discussion and Applicability Statement Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract Lightweight MTA Authentication Protocol (LMAP) is the general term for a family of proposed protocols to help address the spam problem by permitting domains to publish the set of SMTP clients which may use their name in the EHLO/HELO and MAIL FROM fields. SMTP servers can use this information to determine if a client is consensually using a domains name. This document discusses the applicability, and the costs and benefits of wide-spread deployment of the protocol family. Table of Contents Abstract ......................................................... 1 Internet Draft A Discussion of LMAP [Page 1] Internet draft November 2003 1. Introduction .................................................. 3 1.1. Statement from the ASRG chairs ............................ 3 1.2. Summary of the Protocol ................................... 4 1.2.1. Authorization, Authentication, and Intent ............. 5 1.2.2. Semantics of MAIL FROM ................................ 5 1.3. Interpretation of LMAP Data ............................... 6 2. Problem Statement and Scope ................................... 6 2.1. Unauthorized use of a domain name as "forgery" ............ 7 2.1.1. Why prevent domain forgery instead of end-user forgery? 7 2.2 Scope of the proposal ...................................... 8 2.2.1. Domain name in EHLO/HELO .............................. 8 2.2.2. Domain name in MAIL FROM .............................. 8 2.2.3. Source IP address ..................................... 9 2.3 Scope of the Problem ....................................... 9 2.3.1. Junk Email ........................................... 10 2.3.2. Viruses, Trojans, and Worms .......................... 11 2.3.3. Account Fraud, or "phishing" ......................... 11 2.3.4. "Joe-Jobbers" ........................................ 11 2.4. Limitations of the Proposal .............................. 12 2.4.1. Junk Email with Correct Envelope Information ......... 12 2.4.2. "Joe-Jobbing" Within the Same Domain ................. 12 2.4.3. Viruses and Worms using on infected SMTP Server ...... 12 2.5. Accountability for SMTP originators ...................... 12 2.6. Few SMTP originators are SMTP recipients ................. 13 2.7. DNS-based attacks ........................................ 14 3. Common Concerns with LMAP .................................... 14 3.1. LMAP and the end-to-end nature of the Internet ........... 14 3.2. Roaming Users and LMAP ................................... 15 3.2.1. SUBMIT (port 587) .................................... 16 3.2.2. SMTP relaying to their home provider ................. 16 3.2.3. Publish LMAP information ............................. 16 3.2.4. Virtual Private Networks (VPNs) ...................... 16 3.2.5. Other message delivery systems ....................... 16 3.3. Other methods addressing the spam problem ................ 17 3.4. Message relaying and forwarding are affected by LMAP ..... 17 3.5. Inertia to change is not a basis for opposition .......... 18 3.6. Kiosk, greeting card, and mail-a-link systems ............ 18 4. Privacy Considerations ....................................... 19 4.1. End Users ................................................ 19 4.2. Network Infrastructure ................................... 20 4.3. Traffic analysis ......................................... 20 5. Security Considerations ...................................... 20 6. Acknowledgments .............................................. 21 Internet Draft A Discussion of LMAP [Page 2] Internet draft November 2003 7. Informative References ....................................... 21 8. Contact Information .......................................... 21 9. Contributors ................................................. 21 1. Introduction The Anti-Spam Research Group (ASRG) was chartered to address the spam problem. Lightweight MTA Authentication Protocol (LMAP) is the general term for a family of proposed protocols to help address the spam problem by permitting domains to publish the set of SMTP clients which may use their name in the EHLO/HELO and MAIL FROM fields. SMTP servers can use this information to determine if a client is consensually using a domains name. This document discusses the applicability, and the costs and benefits of wide-spread deployment of the protocol family. The LMAP protocol falls with the scope of "changes to existing applications" as described in the charter. The intended audience for this document includes administrators and developers of DNS and SMTP systems. The audience is assumed to be familiar with the workings of SMTP [RFC 2821] and DNS [RFC 1034]. The document is organized as follows. Section 2 describes the problem statement and scope of the proposal. Section 3 deals with the most commonly raised concerns associated with LMAP, and prior variants thereof. We wish to remind readers that implementation and use of LMAP is entirely optional and not required to operate SMTP services. This document is not intended to obsolete anything in RFC 821 or RFC 2821. Readers are further reminded that recipients have the right to refuse any communication from anyone, for any reason. 1.1. Statement from the ASRG Chairs This document is intended to summarize the work of the Anti-Spam Research Group (ASRG) of the IRTF regarding the LMAP family of proposals. This work begun in early 2003 and concluded in early 2004 with the move to the newly chartered MARID WG at the IETF. This document is intended to summarize the work of the ASRG as input to the IETF standards making process and to provide a historical record of the discussions in the ASRG. Readers are encouraged to check current IETF documents for the status of these proposals. As per RFC 2014, section 3, IRTF documents do not require group Internet Draft A Discussion of LMAP [Page 3] Internet draft November 2003 consensus to be published. This document does not have consensus of the ASRG and is being published under this provision. This document does NOT reflect consensus of the ASRG and is being published in accordance with section 3 of RFC 2014. ASRG chairs at the time of writing are John R. Levine and Yakov Shafranovich. 1.2. Summary of the Protocol LMAP is based on two concepts: publication of policy by a domain, and application of that policy by a recipient MTA. The policy published by a domain includes statements as to which IP addresses are intended to claim association with the domain in the SMTP EHLO/HELO and MAIL FROM fields. SMTP recipients can look up this policy when a domain name is used in EHLO/HELO and/or MAIL FROM. The recipient can then choose to apply the requested policy to the message. The result is that messages are delivered only when all parties consent to their delivery. The SMTP client must have the consent of the domain to claim association with that domain, and the SMTP server can verify that that the consent exists. After all, if the domain does not consent to someone claiming association with it, there are few reasons why a recipient would choose to accept that non-consensual message. The method of applying the consent of a domain to messages is similar to that used in Dialup User Lists (DUL). With those methods, a network provider publishes a list of IP addresses which have been assigned to dial-up users. SMTP recipients may query such lists, and assume that the existence of an IP address on the list means that the network provider did not intend SMTP traffic to originate from that IP address. Similarly, methods such as sender callback attempt to discover the implied intentions of a domain, by performing certain queries to that domain. Such methods are flawed, as the implications they discover are not necessarily the same as the intentions of the owner of a domain. This proposal makes all such intentions explicit, through the use of published data by a domain. Publication makes the Internet more open. Less information is hidden, and fewer erroneous implications are arrived at. Note that recipients should also publish that they use and enforce LMAP. Receiving mail transport agents using protocols with the Internet Draft A Discussion of LMAP [Page 4] Internet draft November 2003 ability to advertise capabilities should advertise a capability to the sender that informs the that the sender that the receiver will check the incoming IP address with LMAP. It is to the advantage of all parties for a sender that will not be able to pass LMAP authentication to be able to discover the fact as early as possible and abort the transmission. This verification scheme is weaker than cryptographic systems but stronger than the current SMTP model. 1.2.1. Authorization, Authentication, and Intent There has been significant discussion within ASRG about the proper terms to use when describing the data published and used by this system. The terms authorization and authentication have been proposed. Both terms have their benefits and drawbacks. In this document, we will use both terms when referring to LMAP. An alternate way of describing the proposal is that the data published by a domain expresses the intent that an IP address will, or will not, originate SMTP traffic using that domains name. An SMTP recipient can use that data to learn the intent of the domain owner, and then decide to accept or reject a message based on its conformance with that intent. Whether the publication and application of this intent is best described as authorization or authentication is a decision left to the reader. 1.2.2. Semantics of MAIL FROM There has been significant discussion within ASRG about whether not not this proposal changes the semantics of MAIL FROM. At a minimum, this proposal permits cooperating parties to extend the semantics of MAIL FROM by publishing and using LMAP data. In normal situations, the sender identification used in the MAIL FROM is intended to be used for bounces. The email address used here can therefore legitimately differ from the addresses which are used in the body "From" line. The use of the MAIL FROM field in this proposal can therefore be considered as an additional verification on the bounce path for the message, rather than as an attempt to authenticate the sender identity. As this proposal is intended to be backwards compatible with systems not using LMAP, the semantics of MAIL FROM may remain unchanged when one or more of the parties in the SMTP conversation does not publish or use LMAP data. Internet Draft A Discussion of LMAP [Page 5] Internet draft November 2003 Note that this proposal does not violate the following prohibition from Section 4.1.4 of RCC 2821: An SMTP server MAY verify that the domain name parameter in the EHLO command actually corresponds to the IP address of the client. However, the server MUST NOT refuse to accept a message for this reason if the verification fails The LMAP family of protocols are intended to look up the source IP address of the SMTP connection, within the LMAP data of a domain given in EHLO and/or MAIL FROM. LMAP does not perform a reverse DNS lookup of the source IP address, and therefore does not violate the above prohibition. 1.3. Interpretation of LMAP Data Recipient MTAs are free to interpret LMAP data as they wish. Possibilities range from rejecting email with a 550 error code to using LMAP data as one input to a multi-criterion filter. Domains may also optionally use LMAP data to whitelist or give higher passing values for email in their filters. E-mail from LMAP domains that do not publish LMAP data should NOT be rejected since there is no requirement that domains do so, and many will not, either for policy reasons or from lack of resources. E- mail from non-LMAP domains should be treated as e-mail is treated currently. All local policy decisions remain with the recipient's MTA. Readers are reminded that recipients have the right to refuse any communication from anyone, for any reason. 2. Problem Statement and Scope When an SMTP client connects to an SMTP server, the data in the EHLO/HELO and MAIL FROM fields is supplied by the client to the server. The server must then accept the data within these fields at face value, as there is no provision within SMTP to validate, or authenticate, this data. As a result, SMTP clients who wish to falsely claim association with a domain may use that domains name in those fields within SMTP, and the SMTP server has little choice but to accept that claim. Efforts have been made since the publication of the SMTP specifications to block such messages by requiring the domain part of the sender address to be resolvable. That method provides protection from messages with non-existent sender domains, and indeed, for some time it blocked many spam messages. However, once spammers began to Internet Draft A Discussion of LMAP [Page 6] Internet draft November 2003 abuse existing domain names, that method was rendered ineffective. Other methods such as sender callback have been used to discover the implicit intent of a domain administrator, by verifying that the SMTP client is a valid MTA for the domain it is claiming association with. Such schemes have limited applicability, as the domain may use different MTAs for incoming and outgoing messages. In addition, the implications about a domain that the sender callback implementer comes up with may not be the same as the intentions of the domain administrator. LMAP extends current implementations so that all such intentions may be made explicit by domains, and easily discoverable by SMTP servers. A domain may choose to publish a list of SMTP clients that originate traffic for that domain, and that list does not have to be the same as the list of MXs for the domain. Note that we extend only implementations of SMTP; the protocol itself remains unchanged, and nothing in this document should be construed as modifying or updating any part of the SMTP protocol as defined in RFC 821 or RFC 2821. 2.1. Unauthorized use of a domain name as "forgery" In the context of LMAP, SMTP "forgery" is defined as: SMTP Forgery: Use of a domain name in the argument fields of SMTP EHLO/HELO and/or SMTP MAIL FROM, by an SMTP client, when the owner of the domain name did not consent to that use of their name. Any consensual use of a domain name is therefore defined to not be forgery. As incidents on the Internet over the past few years have shown, mass mails, viruses, and worms with forged sender addresses can cause severe damage for the real owner of the abused sender addresses. While this proposal does not, and will not, stop spam, it will help prevent one of the most damaging forms of spam: forgery. 2.1.1. Why prevent domain forgery instead of end-user forgery? LMAP permits the discovery and prevention of forgery of domain names, rather than of end-user identities for a number of reasons. One is that there are fewer active domains than users. While domain-name registries claim to have registered hundreds of millions of domains, most of those domains are inactive. Statistics from anti-spam organizations indicate that there are only a few hundred thousand MTAs which persist from year to year. These MTAs are the entities which are best suited to participate in a method for addressing the Internet Draft A Discussion of LMAP [Page 7] Internet draft November 2003 spam problem. If LMAP, or another proposal, were to authenticate end-user identities, then those identities would have to be published by a domain, for validation by any SMTP server. That publication would have serious security and privacy implications. We therefore avoid those issues in this proposal by not performing authentication of end-user identities. The use of domain names, rather than end-user identities has another advantage. By discovering forgery of domain names, the recipient MTA can ensure that a valid return path exists for messages which do not contain forged names. This return path verification means that the recipient knows that a responsible party is available to accept either a bounce, or a complaint that the message was spam. 2.2. Scope of the proposal This proposal uses domain names in the EHLO/HELO and MAIL FROM fields of the SMTP protocol, along with the source IP address of the SMTP connection, in order to ask the domain(s) if that IP address was intended to have an SMTP client use its name in the EHLO/HELO or MAIL FROM field. 2.2.1. Domain name in EHLO/HELO In reference to EHLO/HELO, [RFC 2821] says: 4.1.1.1 Extended HELLO (EHLO) or HELLO (HELO) These commands are used to identify the SMTP client to the SMTP server. The argument field contains the fully qualified domain name of the SMTP client if one is available. In situations in which the SMTP client system does not have a meaningful domain name (e.g., when its address is dynamically allocated and no reverse mapping record is available), the client SHOULD send an address literal (see section 4.1.3), optionally followed by information that will help to identify the client system. LMAP can only be applied when the argument to the EHLO/HELO command is a domain name, and when that domain publishes LMAP information. In all other situations, LMAP cannot be applied to the EHLO/HELO command, and this proposal therefore makes no statement about how such an SMTP conversation should be treated. 2.2.2. Domain name in MAIL FROM This proposal also deals with the MAIL FROM field of the SMTP Internet Draft A Discussion of LMAP [Page 8] Internet draft November 2003 protocol. In reference to MAIL FROM, [RFC 2821] says: 4.1.1.2 MAIL (MAIL) This command is used to initiate a mail transaction in which the mail data is delivered to an SMTP server which may, in turn, deliver it to one or more mailboxes or pass it on to another system (possibly using SMTP). The argument field contains a reverse-path and may contain optional parameters. In general, the MAIL command may be sent only when no mail transaction is in progress, see section 4.1.4. The reverse-path consists of the sender mailbox. Historically, that mailbox might optionally have been preceded by a list of hosts, but that behavior is now deprecated (see appendix C). In some types of reporting messages for which a reply is likely to cause a mail loop (for example, mail delivery and nondelivery notifications), the reverse-path may be null. LMAP can only be applied when the argument to MAIL FROM is a sender mailbox from which a domain name can be determined, and when that domain publishes LMAP information. In all other situations, LMAP cannot be applied to MAIL FROM, and this proposal therefore makes no statement about how such an SMTP conversation should be treated. LMAP is therefore not applicable to bounce messages, or to messages pretending to be bounce messages, where no reverse path exists. 2.2.3. Source IP address An LMAP capable SMTP recipient queries the domain(s) using the EHLO/HELO and MAIL FROM fields. The query is the source IP address of the SMTP client. The expected response is, at a minimum, an answer from the set (yes, no, unknown). The recipient can therefore determine if the domain intended SMTP clients at that IP address to send messages in its name. The query syntax, response syntax, and detailed design of this proposal are not documented here, as they are currently in development. 2.3. Scope of the Problem A domain owner may wish to restrict the set of hosts permitted to send email that identifies itself as associated with that domain. LMAP provides a consensual mechanism for domain owners to publish that set of hosts, and for SMTP receivers to discover and to apply that policy to incoming messages. Internet Draft A Discussion of LMAP [Page 9] Internet draft November 2003 In response to RFC 2821 Section 7.1, forged email currently represents a significant burden on the Internet infrastructure. This proposal suggests that the very usability of Internet email is threatened by unwanted and forged messages. In addition, business practices that depend on email are threatened not just by the flood of spam, but also by spam forging a fraudulent association with legitimate businesses. This fraud causes honest businesses to lose significant amounts of income, and increases their expenses. LMAP, though it necessarily implies some increase in the implementation complexity of mail senders and receivers, meets the architectural criteria of RFC 1958. It preserves the end-to-end property of the network; it supplies a mechanism which can be used to implement and experiment with spam-blocking policies. It does not duplicate existing capabilities, and it does not try to do too much. With these considerations in mind, therefore, we believe that adoption of LMAP would currently do more good than harm. See RFC 1958 Section 1. Domains whose email practices would be inconvenienced by LMAP are not required to implement it. Some domains may wish to publish LMAP information, but not to use it themselves. We recommend that domains which use LMAP information also publish it. Domains which choose to implement LMAP will do so because they want to identify outgoing SMTP hosts, in order to authorize email sent using the name of the domain. While it is still possible to send authorized email and be abusive, it becomes far easier to account for that abuse and to identify the sender when an authorization or an audit trail exists. 2.3.1. Junk Email "Spammers," not wishing to be identified or to have their abused resources identified, routinely falsify their emails sender information, including the Sender Envelope (MAIL FROM: envelope), the From: header and the Reply-To: header. Spammers often impersonate large, popular domains when they do this. If such domains implemented LMAP, other participating domains could receive significantly less junk email from spammers falsifying their sender information. In addition, the same verification process could trivially reject spam which is intended to appear to be internal to the domain. Recipients using LMAP could reject any email sent in this manner, regardless of how a resource is exploited. This includes open relay, insecure proxy, dynamic IP, insecure and unrelated resources such as older Formmail versions, and as-yet undiscovered exploits. Internet Draft A Discussion of LMAP [Page 10] Internet draft November 2003 Since this proposal does not examine or verify the body From: field, there is still the possibility for spammers to use that field to fraudulently claim association with a well-known domain. We leave that problem to be addressed by a method other than LMAP. We will recommend, however, that recipients take additional care when accepting messages where the domain in the envelope MAIL FROM does not match the domain in the body "From:". Such messages have greater potential to be forgeries than messages where the domains are identical, and where an accountability system exists. 2.3.2. Viruses, Trojans, and Worms While many malicious programs sometimes use the infected machine's sender address, they rarely use the sender domain's resources to send copies of themselves, instead running their own SMTP engines. Domains implementing LMAP may reject copies of viruses and other malicious software sent in this manner. This method does have limitations, however, see also Section 2.4.3. 2.3.3. Account Fraud, or "phishing" Clients of financial institutions routinely receive communication from confidence artists and scammers claiming association with that institution. The claim is made in order to entice the recipients into divulging critical account information to the scam artist. That information is then used to defraud the client. Similar frauds are perpetrated on clients of non-financial institutions. E.g. Obtaining account information for an ISP, and then abusing that account to send spam. This type of spam is arguable the most damaging of all. It defrauds not only the recipient who naively believes the forged association, but it also defrauds the institution, which is an innocent bystander. Preventing this type of spam alone will save both parties significant time and expense. Account maintainers participating in LMAP can discourage would-be scam artists from falsifying their domain, as participating recipients may reject email from them. 2.3.4. "Joe-Jobbers" A malicious sender may send falsified messages from the email address of an unrelated party, in order to have the recipient blame that third party, rather than the true sender. The first well-known instance of this abuse was against the domain joes.com, hence the phrase "Being Joe'd" or "Joe Jobbing." Internet Draft A Discussion of LMAP [Page 11] Internet draft November 2003 Domains implementing LMAP could greatly diminish their chances of being "Joe'd," as participating recipients could reject such email. 2.4. Limitations of the Proposal As this proposal examines a sub-set of the fields of SMTP, it has certain limitations. It does not prevent "authorized" abuse, such as spammers registering a domain, and publishing LMAP information for that domain. It does, however, make such abuse accountable, and thus easier to track. This proposal does not seek to stop spam, but rather it is another weapon in the arsenal that can reduce the spam problem in combination with other solutions. 2.4.1. Junk Email with Correct Envelope Information LMAP can not stop spammers from using envelope information that they are authorized to use. However, maintainers of spammer's domains could audit their activity more effectively, as the spammers would be forced to use their correct information. If spammers maintain their own domains, domain-based blocking becomes more effective. In extreme cases, where a spammer hosts multiple domains, blocking the authoritative DNS servers for the spammer's domains becomes very effective, as the recipient could reject all LMAP lookups on the spammer's DNS servers. They would effectively reject all email from domains hosted there. 2.4.2. "Joe-Jobbing" Within the Same Domain If a user on example.com falsifies email coming from someone else within example.com, LMAP would permit such forgery, as the sender domain envelope information would be correct. However, the maintainers of that domain could audit this email to identify the sending machine. 2.4.3. Viruses and Worms using an infected SMTP Server If a user's computer executes a virus that, instead of using its own SMTP engine, uses their outgoing mail server, then LMAP would not be able to prevent such abuse. However, domain maintainers could audit this email and identify the infected computer. 2.5. Accountability for SMTP originators The behavior of spammers over the years has made it clear that they do not wish to be held accountable for their actions. They use fraud Internet Draft A Discussion of LMAP [Page 12] Internet draft November 2003 to obtain accounts at legitimate ISPs in order to send spam. They use viruses, trojans, and worms to infect computers owned by other people to send spam. They use trojans to cause innocent bystanders to host Web sites where spam messages send the potential victims of spam-supported fraud. They use accounts in countries or jurisdictions where the spam problem is not recognized, not addressed, or where the legal system permits the sending of spam. While LMAP does not address all of the abusive behavior by spammers, it does address part of the problem. It is therefore only one part of the solution. Other methods must be developed and deployed before spam can be eliminated. This proposal does not address the problem of spammers being hosted by otherwise allegedly reputable network service providers. We recognize that the provider's apparent income from hosting spammers is caused by a failure of accounting practices: the victims of spam have no method to bill the spammer or the originating network service provider for the recipients true costs due to spam. If those costs were billed to the network providers, then spammers would quickly be rejected. We believe that holding network service providers accountable for such behavior will also help to significantly reduce the spam problem. In addition, political, legal, financial, and social solutions to the spam problem are outside of the scope of this proposal. People who are concerned that this proposal will fail because it does not address those issues are encouraged to devote effort to addressing those issues, rather than to attacking this proposal. 2.6. Few SMTP originators are SMTP recipients A large part of the reason for the proposal of this protocol is that few SMTP originators are also SMTP recipients. In addition, the number of SMTP originators is significantly larger than the number of SMTP recipients. This proposal helps to fight spam by redressing that imbalance. For example, the problem of delivering messages to machines with dynamic addresses was solved through the Post Office Protocol (POP) [RFC 1939]. The problem of submitting messages from such machines to an MTA was solved through the Submit protocol [RFC 2476]. SMTP, therefore, may be devoted solely to delivering messages between MTAs. It should not be used for delivering messages to end users from an originator, or for delivering messages from an originator to the final recipients. However, SUBMIT is not currently in wide use. One effect of the Internet Draft A Discussion of LMAP [Page 13] Internet draft November 2003 deployment of LMAP will be to encourage its use. We believe that hosts which do not receive messages by SMTP, should not deliver messages by SMTP. Mail delivery should go out the same way that incoming mail came in. This is not a limitation for those people on the road who plug their portable computer in any hotel room's phone plug and use any provider. If there is a POP server granting download access from anywhere, then the same server should be ready to accept uploading of outgoing messages. It is simply unreasonable to expect that recipient MTAs perform all of the work of authenticating end-users originating messages, and making those users accountable. See Section 3.2 for further explanation of this problem. 2.7. DNS-based attacks DNS poisoning A significant drawback of authentication approaches that involve checking properties of the sender domain is that they allow for a class of denial-of-service attacks. In particular, very large volumes of spam using non-existent sender domains could be used to induce DNS timeouts on the targeted system. However, this problem can be addressed relatively easily by dedicating a DNS server instance to processing sender-domain checks, so that only the processing of incoming mail could be affected, and the cost of the DNS stalls can be expected to be negligible compared to the cost of the spam flood itself. Increased incentive for DNS cracks LMAP will also have the effect of increasing the incentives for spammers to crack and subvert DNS servers (in order to spoof receivers doing LMAP checks against the DNS database). Fortunately, this is a self-correcting problem. If a DNS server is subverted, complaints should make the problem clear very quickly, and corrective action is relatively easy to take. 3. Common Concerns with LMAP This section describes the most common concerns raised about LMAP, and responds in detail to those concerns. 3.1. LMAP does not change the end-to-end nature of the Internet Concerns have been raised that this proposal negatively affects the "end-to-end" nature of the Internet. This section describes why such fears are unfounded. Internet Draft A Discussion of LMAP [Page 14] Internet draft November 2003 The primary reason such fears are unfounded is that this proposal does not change SMTP, except by cooperatively extending the semantics of the MAIL FROM command. The end-to-end nature of SMTP is therefore unchanged. What this proposal does offer is a way to hold the originating end of an SMTP session accountable for any association it alleges it has with a domain. Claims that this accountability is an unwarranted restriction on the "end to end" nature of the Internet should consider that: 1) SMTP originators who wish to be unaccountable for their behavior are called "spammers". The intention of this proposal is to address the problem of spam, not to condone it. 2) SMTP originators who wish to force their messages onto recipients, despite the recipients stated non-consent, are called "spammers". SMTP message delivery has always, and will always, depend on the mutual consent of the parties involved. If a recipient chooses to request that a sender be publicly accountable for his behavior and the sender refuses, then the recipient is free to reject or discard any messages from the sender. The lack of accountability is a major technical reason why spam is such a problem. In fact, this proposal extends the end-to-end principles on which the Internet was built, because it allows each end to publish their policy, and to discover the other end's policy. Sharing of information enhances trust, and permits the discovery of problems related to Man in the Middle (MITM) issues. 3.2. Roaming Users and LMAP Another concern raised about LMAP is that it will negatively affect roaming users. That is, users not connected to their home network. The main concern of roaming users is that the deployment of LMAP will break the "end-to-end" nature of the Internet. The response to those concerns can best be summarized as follows: Stopping mail forgery requires everyone to give up forging. The current practices of roaming users require that the SMTP recipients do significant amounts of work to authenticate or filter their messages. The response, therefore, of recipients, is to request that the roaming user (and the alleged originating domain) share some of that work. This response serves as the foundation for the design of LMAP. Internet Draft A Discussion of LMAP [Page 15] Internet draft November 2003 If the roaming user is unwilling to share the work of demonstrating accountability, then the recipient is free to reject any communication with that roaming user. The simplest way to address the other concerns of roaming users in detail is to list the ways by which they may send email messages in circumstances where LMAP is widely deployed. 3.2.1. SUBMIT (port 587) That is, SMTP on another port [RFC 2476]. Roaming users would use SUBMIT to send messages to their home provider, which would then send those messages to the final recipients via SMTP. This method has all of the benefits of SMTP, with none of the drawbacks of recipients being responsible for authenticating roaming end-users. The primary cost or delay associated with this method is deployment in SMTP client software. 3.2.2. SMTP relaying to a home provider Since many network providers block outgoing SMTP traffic (on port 25), this option is not universally available. The roaming users are then in the awkward circumstance of having their attempt to behave like spammers blocked, by a countermeasure used to prevent spam. 3.2.3. Publish LMAP information Roaming users may update LMAP information for their domain through Dynamic DNS (DDNS). Any messages they send will then pass LMAP criteria, subject to DNS propagation delays. Roaming users can also publish a policy though LMAP that any IP address on the Internet is permitted to claim association with their domain. Administrators who publish such information for their domain should be aware that this practice will open them up to spammers claiming association with their domain. For this reason, we do not recommend such practices. 3.2.4. Virtual Private Networks (VPNs) With this solution, roaming users allow their home provider to authenticate them, and any SMTP traffic is sent through a secure tunnel. That traffic then appears to issue from the network of the home provider, where LMAP information may easily be published and maintained. 3.2.5. Other message delivery systems Internet Draft A Discussion of LMAP [Page 16] Internet draft November 2003 Bi-directional POP, IMAP, Webmail, etc. all exist, and are sub- optimal. But they work. These alternatives have the added benefit that they are not required to scale with the Internet. Rather, they scale with the number of users at a domain. Therefore it is not the problem for the rest of the Internet to deal with these issues, but only a problem for the domain with roaming users. 3.3. Other methods addressing the spam problem Many methods have been proposed to address the spam problem, and some have claimed to be "complete" solutions. It is our belief that no one method, including LMAP, will be a complete solution. Rather, an overlapping set of solutions will be required, each of which address different aspects of the problem. That is, some anti-spam methods are better than LMAP at addressing various aspects of the spam problem. Content filters may catch viruses or trojans originating from a domain implementing LMAP. Blocklists (e.g. RBL) may block spam from domains publishing LMAP data. LMAP alone cannot address these types of message, and is not intended to address them. However, the down side of content filters and blocklists is that they are subject to injection of arbitrary data by the maintainers, where that data may not always satisfy the published criteria for inclusion. It may be difficult for users of these methods to determine why a particular piece of data is listed via the method. In contrast, LMAP relies on public statements in the DNS by a domain, which are easy to verify. Each solution has its costs and benefits, and a limited scope of applicability. We reiterate our belief that no one solution, including LMAP, will fully address the spam problem. 3.4. Message relaying and forwarding are affected by LMAP Mail forwarders have traditionally left the sender envelope untouched. "Forwarding" is used in the sense of the Unix user ".forward" file, and by commercial companies offering forwarding services. Let us examine a situation where an LMAP conformant domain A sends a message to address B which forwards the message to LMAP conformant recipient C using the original sender address from A. If the B->C forward had been set up without the consent of the recipient C, A's LMAP records would be checked by C's LMAP client, and the message Internet Draft A Discussion of LMAP [Page 17] Internet draft November 2003 would be correctly rejected. If the recipient C did desire the B->C forwarding, three workarounds are possible. 1) B's MTA could rewrite the sender address to pass C's LMAP criteria without involving the user B. 2) the user B could alter the .forward such that forwarded messages are reinjected with B's address in the return-path. For example, a .forward that was previously "C@example.com" might now read "|/usr/sbin/sendmail -oi C@example.com" 3) the recipient C could provide a whitelist to C's MTA indicating that forwarded messages are expected to arrive for C from B. LMAP conformant SMTP forwarders should implement a sender rewriting scheme or its equivalent. Forwarders may work around this issue by simply modifying .forward files to pipe messages to a local mailer. 3.5. Inertia to change is not a basis for opposition Many organizations have failed to implement a well-designed mail delivery structure, and have heavily based their network on asymmetry between originator and recipient. Such organizations are hostile to this proposal, because of the effort required to update and re-design their mail infrastructure. While they may have a central mail server for incoming mail, they often permit anyone to send messages alleging association with the organization from anywhere in the world. While such a mail system is simple to implement and maintain, it is also open to abuse. As always, network security has costs. Implementing a secure and well-designed mail system has costs that some organizations are unwilling to bear. This proposal does not affect those organizations in any manner. Rather, it affects the other parties that they communicate with, and permits those parties to request additional accountability from that organization. As long as organizations insist on having policies which are open to abuse, spammers will abuse those organizations and their policies. 3.6. Kiosk, greeting card, and mail-a-link systems Many Web sites offer a facility to mail content from the site to a third party, using the Web surfer's return address. The content may be a greeting card, a magazine article, or a message entered by the user. Few of these sites do any validation of the sender's address. Internet Draft A Discussion of LMAP [Page 18] Internet draft November 2003 They tend to be rate limited or inherently slow enough that they are not useful for sending large volumes of spam. However, since users can enter any return address, the mail they do send is technically indistinguishable from mail with forged return addresses. The most straightforward way to make such systems comply with LMAP would be for them to use their own domain in the return address, while using the user's entered address on the From: line. 4. Privacy Considerations This proposal does not examine message contents, RFC2822 header fields, or user identities in MAIL FROM. It therefore has no privacy considerations which affect those fields. The largest affects of this proposal on privacy are in three areas: end users, publication of the network infrastructure, and traffic analysis. 4.1. End Users This proposal affects the privacy of end users in two ways. First, it permits recipients to associate user identities or message content with a domain that is accountable for the message. Second, it prevents users from gaining anonymity by disassociating themselves from a domain; i.e. forging associations with another domain, or with a non-existent domain. The first affect on privacy has little impact. The user sending the message is already claiming association with a domain, so there is no loss of privacy if that association is verified by the message recipient. Also, as noted previously, this proposal does not prevent users from fraudulently claiming to be another user within a domain. The second affect on privacy is may be considered undesirable by some users. True anonymity through the practice of forged association with domains, forged email addresses, and by sending email through hijacked or trojaned systems will become more difficult. This sort of anonymity is highly correlated with spam, however, and is precisely the kind of abuse that this proposal attempts to prevent. Users who wish anonymity may gain i through accountable mechanisms. Throw-away accounts at reputable network providers may be created and paid for in cash under an assumed name, for example. Other organizations will guarantee a degree of anonymity (more realistically called shelter from others), if certain requirements are met. Internet Draft A Discussion of LMAP [Page 19] Internet draft November 2003 We suggest that accountable methods of creating anonymity be used, rather than unaccountable methods. A few individuals desire for anonymity does not, and should not, require the rest of the Internet to accept large volumes of spam. 4.2. Network Infrastructure Publication of LMAP information results in a readily available list of IP addresses of hosts authorized to send messages associated with a domain. These lists yield information about the network structure, business relationships, and possibly other information about the domain owner, as growing number of domains are owned by single people or families. Such lists may also provide hostile parties with a list of targets for possible attacks. However, such information is often already publicly accessible through other means. Anyone communicating with individuals at a domain may readily obtain this information, and share it with anyone else. Business relationships have been discovered, for example, prior to official public announcements, by examining DNS records. Nearly all such private information about network structure and relationships may therefore be described as already being readily available. If such information is to be kept secret, it is the users responsibility to send messages in such a way as to keep that information private. 4.3. Traffic analysis Any LMAP-aware MTA and DNS server requires additional network traffic compared to servers which are not LMAP aware. This traffic may be analyzed in order to verify that two parties are communicating, or that a particular message has been received. The additional traffic may still be analyzed in this manner, even if the SMTP session itself is encrypted. However, many MTAs already query MX and A records of a domain after receiving a MAIL FROM command, so the additional security threat of this new traffic is minimal. 5. Security Considerations This document describes common uses of LMAP, attacks on it, and defenses which may be implemented. While much of this document deals with security issues, it does not propose any standard, and therefore does not have any direct security effects. However, implementers and administrators of systems using LMAP should be aware of the issues raised herein. Internet Draft A Discussion of LMAP [Page 20] Internet draft November 2003 6. Acknowledgments The author would like to thank Matthew Elvey, David Maxwell, Philip Miller, Eric Raymond, Michael Richardson, and Yakov Shafranovich for feedback on prior versions of this document. 7. Informative References [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] Hoffman, P. "SMTP Service Extension for Secure SMTP over TLS", RFC 2487, January, 1999 [4] Myers, J. "SMTP Service Extension for Authentication", RFC 2554, March, 1999. [5] Klensin, J. (Ed) "Simple Mail Transfer Protocol", RFC 2821, April 2001. [6] Mockapetris, P., "Domain Names - Concepts and Facilities", RFC 1034, November 1987 [7] Carpenter, B. (Ed), "Architectural Principles of the Internet", RFC 1958, June 1996 [8] Gellens, R. and Klensin, J., "Message Submission", RFC 2476, December 1998 [9] Myers, J. and Rose, M., "Post Office Protocol - Version 3", RFC 1939, May 1996. 8. Contact Information Alan DeKok IDT Canada, Inc. 1575 Carling Ave. Ottawa, ON K1G 0T3 Canada Email: alan.dekok@idt.com Phone: +1 613 724 6004 ext. 231 9. Contributors The following contributors (in alphabetical order) have proposed Internet Draft A Discussion of LMAP [Page 21] Internet draft November 2003 various protocols within the LMAP family. While this document summarizes the concepts behind their work, the reader is asked to consult with the individual contributors for the latest drafts of their proposals. At the time of publication, none of the proposals had status other than Internet-Draft, so they are not referenced here. For informational purposes, the acronym of the LMAP proposal is given in brackets after the contributors name. Raymond S Brand (DRIP) P.O. Box 100486 Ft. Lauderdale, FL 33310 US Email: rsbx@acm.org Hadmut Danisch (RMX) Tennesseeallee 58 76149 Karlsruhe Germany E-Mail: rfc@danisch.de Phone: ++49-721-843004 or ++49-351-4850477 Gordon Fecyk (DMP) Pan-Am Internet Services 24 - 482 Young Street Winnipeg, MB R3B 2S6 Canada Email: gordonf@pan-am.ca Phone: +1 204 292-9970 John R. Levine (FSV) Taughannock Networks PO Box 727 Trumansburg NY 14886 USA E-mail: johnl@taugh.com Phone: +1 607 330 5711 Richard W Rognlie (DRIP) 2782 Prince Harold Ct Oak Hill, VA 20171 US Email: ietf-drip-draft@spamblock.gamerz.net Laurence Sherzer (DRIP) P.O. Box 5072 Deerfield Beach, FL 33442 US Email: laurence@sherzer.net Internet Draft A Discussion of LMAP [Page 22] Internet draft November 2003 Meng Weng Wong (SPF) IC Group, Inc. 105 S 12TH ST STE 310 Philadelphia, PA 19107 USA Email: mengwong@pobox.com Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Internet Draft A Discussion of LMAP [Page 23]