[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

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

   The list of Internet-Draft Shadow Directories can be accessed at

   Copyright Notice

    Copyright (C) The Internet Society (2004).  All Rights


   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

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

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

   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

   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

   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

   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:  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: 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

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

   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

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

   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

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

   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

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

   [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
   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
   Email: rsbx@acm.org

   Hadmut Danisch (RMX)
   Tennesseeallee 58
   76149 Karlsruhe
   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
   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
   Email: ietf-drip-draft@spamblock.gamerz.net

   Laurence Sherzer (DRIP)
   P.O. Box 5072
   Deerfield Beach, FL  33442
   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
   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

   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

Internet Draft      A Discussion of LMAP                       [Page 23]

Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/