[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
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]
Html markup produced by rfcmarkup 1.129c, available from
https://tools.ietf.org/tools/rfcmarkup/