First draft of the "discussion" paper.
"Alan DeKok" <[email protected]> Mon, 03 Nov 2003 15:49:25 -0500
| Newsgroups | gmane.ietf.asrg.rmx |
|---|---|
| Message-ID | <[email protected]> |
As Yakov requested last week, I've written a first draft of the
"discussion" paper about the protocol. Some things to remember:
- I haven't (as yet) finished the related protocol document. When
written, it will be substantially based on the current SPF draft,
which is in turn based on the earlier work (Vixie, RMX, DMP, DRIP,
DSProtocol...)
- the document assumes some familiarity with SMTP, DNS, and the
previous RMX-style proposals.
- The name is now "LightWeight MTA Authentication Protocol", or LMAP
- the document still needs more work. Please supply REPLACEMENT TEXT
if you have any comments on it. Comments like "section 6 is wrong"
will be rejected out of hand.
- I'm listed as Editor, and all of the authors listed on the drafts
are listed as "contributing authors". Send flames to me, kudos to
the authors.
- much of the text in this document may be better suited for the
protocol document (e.g. security / privacy considerations).
Suggestions are welcome.
- The text in the document is STRONGLY WORDED. If you want it toned
down, SUBMIT REPLACEMENT TEXT.
- I can't emphasize enough that the text is strongly worded. I've
had too many bad experiences with yahoos on ASRG, because they're
unwilling, or unable, to read and understand any of the proposals.
Alan DeKok.
----------------------------------------------------------------------
Internet Draft A. DeKok (Ed.)
Expiration: April 3, 2004 IDT, Inc.
Working Group: Forces November 3, 2003
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 (2003). All Rights
Reserved.
Abstract
The Lightweight MTA Authentication Protocol (LMAP) [ref] has been
proposed as a method to help address the spam problem. That document
describes the design of the protocol. This document discusses the
applicability, and the costs and benefits of wide-spread deployment
of that protocol.
Table of Contents
Abstract...........................................................1
(TBD: Rest of the table of contents)
1. Introduction
Internet Draft A Discussion of LMAP [Page 1]
Internet draft November 2003
The Anti Spam Research Group (ASRG) was chartered to address the spam
problem. The charter states:
"The purpose of the ASRG is to understand the problem and
collectively propose and evaluate solutions to the problem.
While some techniques focus on local text classification
approaches, many traditional and evolving techniques include
approaches that involve new network architectures or changes to
the existing applications and protocols."
The LMAP protocol falls with the scope of "changes to existing
applications".
The intended audience for this document includes administrators and
developers of DNS and SMTP systems. The audience are assumed to be
familiar with the workings of SMTP [RFC2821] and DNS [RFC1034].
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. Section 4 addresses the ASRG requirements, as
given in [ASRG requirements]. Section 5 addresses the technical
considerations, as given in [Crocker-technical-considerations].
We wish to remind readers that implementation and use of LMAP is
entirely optional and not required to operate SMTP services. This
document not not obsolete, modify, or update 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 Summary of the Protocol
The LMAP design document [ref] discusses the detailed design of the
protocol. A descriptive summary is given here for informational
purposes only. (Ed.: The LMAP design document is as yet unfinished.
When published, it will be substantially similar to the SPF proposal,
which is in turn based on the previous proposals; Vixie, RMX, DMP,
DRIP, DSProtocol, SPF.)
LMAP is based on two concepts: publication of policy by a domain, and
application of that policy by a recipient MTA. The combination of
these concepts permits SMTP originators and recipients to reach more
informed consent when exchanging messages.
The policy published by a domain includes statements as to which IP's
are permitted to claim association with the domain in SMTP EHLO/HELO
Internet Draft A Discussion of LMAP [Page 2]
Internet draft November 2003
and MAIL FROM. That policy can request certain decisions to be made
by a recipient on behalf of the domain. For example, "mail from
example.com originates solely from the machine mail.example.com.
Please reject mail allegedly from example.com which originates
elsewhere."
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
message originator must have the consent of the domain to claim
association with that domain, and the recipient can verify that that
consent exists. After all, if the domain does not consent to an
originator 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) [ref: Orca]. 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.
Similarly, methods such as [postfix] 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 implications intended by the owner of a domain. (Ed.:
See posts to ASRG on this topic)
This proposal makes all such intentions explicit, through the use of
public policy statements by a domain. Publication of such policies
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/enforce LMAP.
(Ed.: This topic should be addressed in more detail.)
This verification scheme is weaker than cryptographic systems but
stronger than the current SMTP model.
2 Problem Statement and Scope
LMAP addresses the problem of forgeries in the argument field of SMTP
EHLO/HELO, and SMTP MAIL FROM. It does not use or examine any other
argument of any other field of the SMTP protocol. Specifically, no
information in the body (DATA portion) of an SMTP message is used in
any part of LMAP. Examination, validation, or verification of the
Internet Draft A Discussion of LMAP [Page 3]
Internet draft November 2003
body "From:" is explicitly not part of this proposal, and this
proposal should not be represented as using body "From:".
2.1 What is meant by "forgery"?
In the context of LMAP, "forgery" is defined as:
Forgery: Use of a domain name in the argument field of SMTP
EHLO/HELO, and/or SMTP MAIL FROM, by an SMTP client, without the
knowledge or consent of that domain.
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 does forgery exist?
Forgery exists because there is no method within SMTP to discover or
prevent it. The protocol was designed at a time where security was
not an issue. Efforts have been made since the publication of the
SMTP specifications to block forged e-mails by requiring the sender
address domain part to be resolvable. That method provides
protection from e-mails with non-existent sender domains, and indeed,
for some time it blocked many spam e-mails. However, once attackers
and spam senders began to abuse existing domain names, that method
was rendered ineffective.
The goal of LMAP is to extend implementations of SMTP so that domains
may protect themselves from forgery, and recipients may discover such
forgery. Note that we extend only implementations of SMTP; the
protocol itself remains unchanged, and nothing in this document or
[ref: the protocol] should be construed as modifying or updating
anything in RFC 821 or RFC 2821.
2.1.2 Why prevent domain forgery, instead of end-user forgery?
We propose to discover and prevent forgery of domains, rather than
forgery of end-user identities, because 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 used to address the
Internet Draft A Discussion of LMAP [Page 4]
Internet draft November 2003
spam problem.
(Ed.: The following paragraphs may not be appropriate for this
draft.)
In addition, SMTP AUTH [ref] has done nothing to stop spam. Spammers
will always claim that their users are authenticated, so SMTP AUTH
does nothing on the sender side to prevent spam. On the recipients
side, the recipient simply does not have sufficient information to
authenticate all of the users on the entire Internet who wish to send
it email messages. So SMTP AUTH does nothing on the recipient side
to prevent spam.
In addition, if authentication information for users of a domain were
to be published, then that publication would have serious security
implications. We therefore do not recommend such methods of
addressing the spam problem.
Challenge-response methods have similar issues. They are an attempt
to authenticate end users, and have had mixed success. Many
recipients of challenges simply discard the challenge, and fail to
reply. This practice limits the effectiveness of these systems
against spam, and also results in legitimate messages being dropped.
2.2 Scope of the proposal
This proposal deals with the EHLO/HELO fields of the SMTP protocol.
In reference to EHLO/HELO, [RFC2821] 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.
This proposal also deals with the MAIL FROM field of the SMTP
protocol. In reference to MAIL FROM, [RFC2821] says:
Internet Draft A Discussion of LMAP [Page 5]
Internet draft November 2003
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.
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 assocaited 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.
In response to RFC2821 section 7.1, forged email currently represents
a significant burden on 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. With these
considerations in mind, therefore, we believe that adoption of LMAP
would currently do more good than harm. See RFC1958 section 1. (Ed.:
We need additional text here.)
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.
Internet Draft A Discussion of LMAP [Page 6]
Internet draft November 2003
Domains which choose to implement LMAP 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 audit
trail exists.
2.3.1 Junk Email
"Spammers," not wishing be identified or have their abused resources
identified, routinely falsify their email's sender information,
including Sender Envelope (MAIL FROM: envelope), From: header and
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.
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.
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 assocation 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 matcg 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 itself, 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
Members of financial institutions, and non-financial account
maintainers, routinely receive communication from confidence-artists
and scammers falsifying the membership host's domain in their email.
They do this to entice the recipients into divulging critical account
Internet Draft A Discussion of LMAP [Page 7]
Internet draft November 2003
information to the scam artist.
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"
Malicous people wishing to harm another person on the Internet often
falsify someones email address to direct blame on that other person.
The first well-known instance of this abuse put the domain joes.com
out of business, hence the phrase "Being Joe'd" or "Joe Jobbing."
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
it. It does, however, make such abuse accountable, and thus far
easier to track.
2.4.1 Junk Email with Correct Envelope Information
LMAP can not stop a spammer from using envelope information that they
are authorized to use. However, maintainers of a spammer's domain
could audit their activity more effectively, as the spammer is 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 spammers' 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
Internet Draft A Discussion of LMAP [Page 8]
Internet draft November 2003
domain envelope information would be correct. However, maintainers
of that domain could audit this email and identify the sender.
2.4.3 Viruses and Worms using the Infected Party's SMTP Server
If a user's computer runs such 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 user with the infected computer.
2.5 Accountability for SMTP originators
The behaviour of spammers over the years have made it clear that they
do not wish to be held accountable for their actions. They use fraud
to obtain accounts at legitimate ISPs to send spam. They use
viruses, trojans, and worms to infect computers to send spam. They
use trojans to force innocent bystanders to host web sites where spam
messages refer may refer people to. They use accounts in countries
where the spam problem is not recognized, and not addressed.
While LMAP does not address all of the abusive behaviour by spammers,
it does address part of the problem. It is therefore only one part
of the solution. Other methods will be required to be developed and
deployed before spam is to be eliminated.
This proposal does not address the problem of spammers being hosted
at otherwise allegedly reputable network providers. We recognize
that the providers 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 network provider for their costs due to spam.
If those costs were billed to the network providers, then spammers
would quickly be rejected. We believe that holding network providers
accountable for such behaviour will also help to significantly reduce
the spam problem.
In addition, political, legal, monetary, and social solutions to spam
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 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.
Internet Draft A Discussion of LMAP [Page 9]
Internet draft November 2003
For example, the problem of delivering messages to machines with
dynamic addresses was solved through the Post Office Protocol (POP)
[ref]. The problem of submitting messages from such machine to an
MTA was solved through the Submit protocol [ref]. 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
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 reciepient MTAs perform all of the work
of authenticating end-users originating messages, and making those
users accountable. See Section 3.2 for further exposition of this
problem.
2.7 DNS based attacks
(Ed,: This section needs work.)
DNS poisoning
Columes of spam using non-existent domains, causing DNS timeouts.
3. Common Concerns with LMAP
Detailed responses to the [requirements] and [technical]
considerations documents are given below, in Sections [ref] and
[ref]. 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.
The primary reason such fears are unfounded is that this proposal
does not change SMTP in any manner whatsoever. The end to end nature
of SMTP is therefore unchanged. What this proposal does offer is a
Internet Draft A Discussion of LMAP [Page 10]
Internet draft November 2003
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 be aware of two simple facts:
1) SMTP originators who wish to be unaccountable for their
behaviour 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 behaviour and the sender refuses, then the
recipient is free to reject or discard any messages from the
sender.
The lack of accountability is the number technical one 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 others policy. Sharing of information
enhances trust, and permits the discovery of problems related to Man
in the Middle (MITM) issues.
3.2 Roaming Users are mostly unaffected by LMAP
Another concern raised about LMAP is that it will negatively affect
roaming users. The characterization of this opposition as "concern"
is a gross minimization of the hostility to this proposal from users
who refuse to stop forging messages. At the extreme, the statements
of "concern" about the wide-spread deployment of LMAP claim that this
proposal will only be useful through the imposition of a global
dictatorship.
We are unclear as to why such polemics are necessary (to say nothing
of the dictatorship.) There has been no response given to requests
about the rationale for such beliefs, and the only conclusion that we
can draw is that there are hidden agendas behind such statements. We
encourage individuals opposing LMAP to publicly acknowledge their
agendas, along with technical reasons (if any) for opposing the
proposal.
The main concern of roaming users is that the deployment of LMAP will
break the "end to end" nature of the Internet. The previous section
refutes that concern in detail. This section gives more specific
Internet Draft A Discussion of LMAP [Page 11]
Internet draft November 2003
reasons as to why the other concerns of roaming users are unfounded.
The response to those concerns can best be summarised as follows:
Stopping mail forgery requires every one of them to give up
forging.
The practices of roaming users currently require that the SMTP
recipient 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.
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. Any complaints about such
rejection should be directed to the administrators of the recipient
MTA, and not to the authors of this proposal. Rather than attacking
a proposal which permits them to be held accountable for their
actions, roaming users should accept that accountability.
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 [ref]. 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 only cost or delay associated with this method is deployment in
SMTP client software.
3.2.2 SMTP relaying to their home provider
This proposal is sub-optimal, as many network providers block
outgoing SMTP traffic (on port 25). The roaming users are then in
the awkward circumstance of having their attempt to behave like
spammers blocked, by an attempt to prevent spam.
We do not, however, recommend that network providers block outgoing
SMTP. That is a misguided policy which may cause unwarranted
difficulty to legitimate end users.
Internet Draft A Discussion of LMAP [Page 12]
Internet draft November 2003
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
criteries, subject to DNS propogation 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.
LMAP also provides a method by which domains can associate themselves
with other domains, so that users roaming within domain-2 can still
claim association with domain-1. Of course, this method also means
that non-roaming users in domain-2 can send spam claiming to be from
domain-1.
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
Bi-directional POP, IMAP, Webmail, etc. all exist, and are sub-
optimal. But they work.
They also 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. So it is not the problem of the rest of the Internet to deal
with those issues, but instead the domain with roaming users.
3.3 Content filters are insufficient to address the problem alone
Content filters suffer from a fundamental design problem: they are
too late. The message has already been accepted. In addition, they
need permit some distribution of spam, in order to learn about its
content, and then to block further distribution. We are unclear as
to why it is considered acceptable use of the network to permit large
volumes of garbage to flow over the network, simply because the final
recipient of can throw that garbage away. Such inefficient use of
network resources is acceptable only when no other alternative
exists. LMAP is being proposed to help create an alternative.
Internet Draft A Discussion of LMAP [Page 13]
Internet draft November 2003
Content filters also suffer from the problem that they may censor
legitimate email, and not just spam. We have seen evidence that
distributed email content filtering schemes have been abused in
precisely this manner, despite claims that their only purpose was to
fight spam. We have also seen evidence that web-based filters to
"protect your child from bad content on the net" have been used to
filter out pages which are critical of the filter product, and other
pages which the authors of the filter product disagree with. We
recommend that users of any content filtering methods take great care
with systems where the content of the filters are opaque to the user.
Nothing in this proposal prevents recipients from implementing
content filters in addition to LMAP. Despite the problems with
content filters, careful use of them along with LMAP may reduce spam
more than either method applied alone.
However, as this proposal does not examine message content, it does
not suffer from the flaws and abuses of content filtering methods.
3.4 Message relaying and forwarding are affected by LMAP
(Ed.: See also the response to [technical] 4.5 (16), in Section
5.1.16, below)
Mail forwarders have traditionally left the sender envelope
untouched. "Forwarding" is used in the sense of *ix user .forward
and /etc/aliases files.
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
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 "[email protected]"
might now read "|/usr/sbin/sendmail -oi [email protected]"
3) the recipient C could provide a whitelist to C's MTA
indicating that forwarded messages are expected to arrive for C
Internet Draft A Discussion of LMAP [Page 14]
Internet draft November 2003
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 organisations have failed to implement a well-designed mail
delivery structure, and have heavily based their network on asymmetry
between originator and recipient. Such organisations 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 organisation 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 organisations are unwilling to bear. This proposal does not
affect those organisations in any manner. Rather, it affects the
other parties that they communicate with, and permits those parties
to request additional accountability from that organisation.
As long as organisations insist on having policies which are open to
abuse, spammers will abuse that organisation and its policy.
3.6 Allegations about "Freedom of Speech" are unfounded
Opponents to this proposal have claimed that it infringes on their
"freedom of speech". Such opponents are strongly encouraged to read
(and rediscover) the legal documents which protects such freedoms.
Those documents are contract between a government and the citizens of
a country. The "freedom of speech" limitation is solely a limitation
on the governments ability to restrict consensual communication
between its citizens.
An individuals "freedom of speech", therefore, is not infringed if
the recipient of their speech does not consent to listen. An
individuals "freedom of speech" is also not infringed if the
government is not involved in the communication.
Individuals who require that others be forced to listen to their
"free speech" will quickly discover that those listeners are
extremely hostile to such requirements. We further note that these
claims of "freedom" can only be realized through the oppression of
others. Those desires for "freedom", therefore, are simply an
immoral excuse for such oppression.
Internet Draft A Discussion of LMAP [Page 15]
Internet draft November 2003
"Freedom of speech" does not involve forcing recipients to accept
messages with forged and fraudulent content.
4. Addressing the ASRG Requrements
This section provides a point by point response to the issues raised
in the ASRG requirements document.
4.1.1 Requirement 2.1, Use of existing RFCs.
LMAP leverages existing network protocols such as SMTP [ref] and DNS
[ref]. LMAP extends the use and interpretation of those protocols,
but does not modify them.
4.1.2 Requirement 2.2, Inexpensive
The computational expense of LMAP is limited to text parsing (SMTP
fields, and LMAP data), and a few DNS lookups. The storage expense
of LMAP information is minimal, no more than a few kilobytes per
domain.
4.1.3 Requirement 2.3, Unencumbered
LMAP is not encumbered by any restrictions that we are aware of.
4.1.4 Requirement 2.4, Ease of Use
LMAP does not interact with message senders or recipients. LMAP does
not interact with originating MTAs. The only users of LMAP
information will be recipient MTAs. Many MTAs have methods by which
decisions may be made about a message. LMAP gives those methods more
information by which to make their decisions, through the use of DNS
and a simple information language. In order to use LMAP, message
system managers will have to configure their MTAs to query and parse
LMAP information.
4.1.5 Requirement 2.5, Ease of Deployment
LMAP uses the existing protocols of SMTP and DNS. Neither protocol
is changed, minimizing the deployment cost of LMAP. Administrators
of DNS databases may add LMAP information, in the form of additional
TXT records for their domain. Administrators of MTAs may be required
to upgrade their MTA software, in order to query and use LMAP
information.
4.1.6 Requirement 2.6, Interoperable
LMAP does not change SMTP or DNS. Any system using LMAP is therefore
Internet Draft A Discussion of LMAP [Page 16]
Internet draft November 2003
no more, and no less, interoperable than it was before.
Note that MTAs implementing LMAP may choose to not communicate with
systems not implementing LMAP. This choice is a result of local site
policy, and does not affect the interoperability of the protocols.
4.1.7 Requirement 2.7, Highly Effective
There has been much discussion within ASRG as to the effectiveness of
LMAP. We will note that there are similar systems to implicitly
discover information which LMAP makes explicit.[postfix] Those
systems have been widely deployed for some time, and their proponents
claim a significant reduction in delivered spam.
4.1.8 Requirement 2.8, Persistently Effective
Once deployed, LMAP will be persistently effective within its
intended scope. However, as with any static method of defense, it
may be circumvented through new attacks.
4.1.9 Requirement 2.9, Doesn't Interfere With The Delivery Of Legitimate
Mail
LMAP has no impact on the delivery of any messages. The information
supplied to an MTA by LMAP may be used by that MTA to make decisions
about acceptance or rejection of a message, but those decisions are
local site policy, and are outside of the scope of LMAP.
4.1.10 Requirement 2.10, Single Solution
LAMP is not a comprehensive solution to the spam problem. It is
simply one method which helps address a subset of the spam problem.
4.1.11 Requirement 2.11, Technical Rather Than Legislative
LAMP is solely a technical solution. Legislation is not required to
make the protocol useful.
It can be suggested that the publication of LMAP information be
legislated. We do not, however, see such legislation as being
beneficial or effective.
4.1.12 Requirement: 2.12, Complexity
LMAP may be understood in simple terms. An IP (or IPv6) address and
a domain name are used to obtain information through DNS about the
SMTP relationship between that domain name, and that IP (or IPv6)
address.
Internet Draft A Discussion of LMAP [Page 17]
Internet draft November 2003
The information returned via DNS is a publication of site policy.
Any recipient MTA can use that published site policy to determine if
a particular SMTP session is conformant to that policy. If not, the
recipient MTA can choose to reject the SMTP communication as non-
conformant.
4.1.13 Requirement 2.13, Implementation Ability
LMAP (and related variants) have multiple existing implementation.
Due to the simplicity of the design of the protocol, and the use of
existing protocols, implementation of LMAP is simple and low-cost.
4.1.14 Requirement 2.14, Other Platforms
The design of LMAP may be extended to publish similar site policy for
protocols other than SMTP. Those extensions are outside of the scope
of this document.
4.1.15 Requirement 2.15, Accountability and Anonymity
LMAP allows a domain to be held accountable for messages which claim
to be associated with that domain. LMAP impacts user anonymity only
in that their messages may now be authenticated as originating from a
domain. LMAP does not examine or enforce user identity, or
accountability
Spammers may register domain names and provide LMAP information for
those domains. LMAP does nothing to prevent such spam, though it
does make those domains accountable for the messages.
LMAP allows domains to not be held accountable for spam which
fraudulently claims an association with that domain.
5. Addressing the Technical Considerations document
This section provides a point by point response to the issues raised
in the Technical Considerations document. Duplicate responses are
given in areas where that document overlaps with the ASRG
requirements document, and where that document also addresses
concerns discussed in Section 3, above.
5.1.1 Factor 4.1 (1), Adoption Effort
The adoption effort to publish for LMAP for domains is limited to
updating TXT records in DNS. We expect that administrators for many
domains can create this information by following a few simple recipes
for common situations, such as:
Internet Draft A Discussion of LMAP [Page 18]
Internet draft November 2003
a) permitting any IP address to claim association with that
domain,
b) permitting only the existing MXs for the domain to claim
association,
c) permitting only IPs within a particular network or networks
to claim association.
More complex configurations will require more work by the domain
administrator.
LMAP currently requires no changes to existing DNS implementations.
In the future, if the LMAP information is published in a new DNS
record, then implementation changes may be required.
For recipient MTAs, LMAP requires that the implementions be upgraded
to query LMAP records, parse them, and then perform decisions based
on the combination of returned information and local site policy.
Earlier variants of the protocol [SPF] have been implemented in some
of the widely used MTAs, so we believe that this barrier to adoption
is low.
The site policy for recipient MTAs is also expected to commonly
follow simple recipes, such as:
a) when no LMAP record is found, behave in the same manner as
previously, when LMAP was not implemented,
b) follow the directions of the LMAP response for a domain,
c) reject all mail from domains which do not have LMAP records
More complex configurations will require more work by the domain
administrator.
5.1.2 Factor 4.1 (2), Threshold to benefit
Early adopters of previous variants of LMAP have claimed reductions
in spam.
(Ed.: We need additional text here.)
4.1.5 Factor 4.1 (3), Impact on participants
LMAP as no impact on recipients for message delivery, other than
providing them with more information than was previously available.
Use of LMAP may open recipient MTAs to DNS attacks, through the use
Internet Draft A Discussion of LMAP [Page 19]
Internet draft November 2003
of non-existent domain names in malicious SMTP sessions. The
recipient MTA may be forced to wait for a DNS timeout (NXDOMAIN)
before proceeding with the SMTP session. Large volumes of such
malicous traffic may constitute a Denial of Service (DoS) attack
against an MTA. Implementors should be aware of this possibility,
and attempt to protect against it.
The impact of LMAP on originating MTAs is only that LMAP information
must be available in DNS for those MTAs. If not, their messages may
be rejected.
LMAP has no impact on end users who receive SMTP messages.
The impact of LMAP on end users originating SMTP messages is
discussed in (Ed.: refer to other sections.)
5.1.4 Factor 4.1 (4), Impact on Others
LMAP has no impact on SMTP recipients who do not implement the
protocol. The mere existence of LMAP information does not, and can
not, affect the behaviour of systems which ignore that information.
The impact of LMAP on SMTP originators who do not implement the
protocol is more complicated. That impact depends solely on the
local site policy of the SMTP recipient which does implement LMAP.
The recipient may choose to make no decision (an implicit accept)
about a message, if it does not discover LMAP information. In this
case, the behaviour of both originator and recipient is unchanged
from their behaviour without LMAP.
The recipient MTA may chooses to make a decision other than "accept",
about the message, based on the non-existence of LMAP information.
That decision may range from passing the message through a more
stringent examination, to rejecting the message outright. To those
who claim that this decision affects legitimate users of email who do
not choose to implement LMAP, we can only say that nothing in SMTP
ever guaranteed that a message would be accepted or delivered to a
final recipient. We suggest that those legitimate users of email
contact the administrator of the recipient MTA implementing LMAP, to
discuss their interaction with local site policy.
5.1.5 Factor 4.2 (5), Ongoing Effort
The ongoing effort to use LMAP is limited solely to automated systems
performing DNS lookups, and making policy decisions based on any
returned data. For systems which achieve mutual consent through
LMAP, there will be no affect on end users. For systems which do not
achieve mutual consent (through LMAP or other methods), some email
Internet Draft A Discussion of LMAP [Page 20]
Internet draft November 2003
messages may not be delivered. This failure to deliver is no, and
can not, be made the responsibility of LMAP. It is solely due to the
failure of message originator and recipient to achieve consent.
5.1.6 Factor 4.2 (6), Balance of Burdens
Implementation of this proposal increases the burden of SMTP
recipients as compared to SMTP originators. The recipient must query
LMAP information for each domain which sends it messages, and make
decisions based on the returned information. In contrast, originating
MTAs have nothing to do, as all of the work of publishing LMAP
information is done via DNS.
The participant in SMTP exchanges who is affected the most by LMAP is
the "roaming user". The burden allegedly imposed on this user is
discussed in detail in Section [here]. Our only comments here will
be that so far as the recipient can tell, roaming users are
indistinguishable from spammers. LMAP is based on the consent of
both the recipient and the originator, and originators who do not
consent to behave in an accountable manner should not complain that
recipients do not consent to accepting their messages.
5.1.7 Factor 4.3 (7), Use by Full Internet
If all MTAs and DNS servers on the Internet implement LMAP, then
every domain may be held accountable for messages which are allegedly
associated with that domain. The fabric of Internet mail is not
substantially affected by such accountability.
5.1.8 Factor 4.3 (8), Growth of the Internet
If the Internet grows by a factor of 1000, then this proposal does
not necessarily become 1000 times more expensive. The cost of using
LMAP depends solely on the number of messages received by an MTA, and
on the number of domains from which those messages claim to
originate. It is therefore to a large extent, independent of the
number of MTAs or domains on the Internet.
5.1.9 Factor 4.3 (9), Efficiency
The amount of work and space required to store and publish LMAP
information is minimal, a few kilobytes per domain. The work and
space required for recipient MTAs to request and remember LMAP
information is also minimal. The proposal therefore exhibits
efficiency of time and space.
5.1.10 Factor 4.3 (10), Cost
Internet Draft A Discussion of LMAP [Page 21]
Internet draft November 2003
Costs associated with LMAP are largely those associated with
configuring and maintaining DNS, and MTAs for a domain. These costs
are incremental over current costs, and slightly increase the effort
required to maintain systems when MX records change, or when MTAs are
upgraded.
5.1.11 Factor 4.3 (11), Reliability
The proposal depends on existing network infrastructure and
protocols, and is thus largely no more, and no less, reliable than
current systems. The part of the proposal which affects reliability
the most is that MTAs implementing LMAP will perform more DNS lookups
than MTA which choose to not implement LMAP. Additional complexity
and work always have some effect on reliability.
5.1.12 Factor 4.3 (12), Internet Impact
This proposal implements consent publication and enforcement between
a recipient MTA, and a domain which is allegedly associated with an
originating MTA. No other parties are affected by this proposal, and
nothing else on the Internet changes, if this proposal is adopted.
5.1.13 Factor 4.3 (13), Spam Impact
This proposal will not stop all spam. It may, however, have a
significant impact on the most damaging spam: viruses and "Joe Jobs".
Section 2.3 discusses this impact in more detail.
5.1.14 Factor 4.4 (14), Circumvention
Spammers may bypass this scheme through a number of methods, such as:
- Claiming association with a domain not implementing LMAP
- Claiming association with a domain implementing LMAP, but
which has a policy stating anyone can claim such association.
- "Hijacking" systems or MTAs within a domain to send spam.
- DNS poisoning, to force particular LMAP information on an MTA
- Registering domains, and implement LMAP.
Recipients can use methods other than LMAP to defend against such
attacks. These methods may include whitelists, blacklists, greylists
[ref], and content filtering. There is no requirement that LMAP be
the only source of information for implementing site policy.
Internet Draft A Discussion of LMAP [Page 22]
Internet draft November 2003
LMAP makes no claim to stop all spam. Rather, it "raises the bar"
for sending spam. The above circumvention methods all require
additional work by the spammer, and some require significant
additional work.
These circumvention efforts by spammers do nothing more than expose,
and take advantage of, existing flaws within the Internet. LMAP
should not be held responsible for existing insecure implementations
or practices, even if those insecurities are exposed to more scrutiny
through the deployment of LMAP.
5.1.15 Factor 4.5 (15), Personal Post/Reply.
For two individuals who wish to initiate contact, LMAP requires that
that intention be made public via DNS. For ongoing contact, LMAP
requires no additional work.
5.1.16 Factor 4.5 (16), Mailing Lists
Mailing lists which do not use their own domain name in the EHLO
field of SMTP may be severely affected by LMAP. Such MTAs are rare.
Most current mailing list software rewrites the MAIL FROM, to permit
bounces to be sent back to the mailing list administrator. These
lists will be unaffected by LMAP (other than the issues raised
above).
Mailing lists which do not rewrite the MAIL FROM may be severely
impacted by LMAP. Such lists are arguably broken, however, and
should be upgraded. (Ed.: Is there an RFC 2821 recommendation we can
quote here?)
The one practice which will be most affected by LMAP is the use of
".forward" files. Widespread use of LMAP may make the use of
.forward files problematic.
We recognize that every MTA using .forward files on *ix hosts or
similar configurations do not alter the sender envelope when
forwarding mail. However, commercial and proprietary mail-forwarding
systems alter the sender envelope, and these are by far the most
popular pure mail-forwarding instances.
There is no fix for .forward usage aside from altering the sender
envelope and designating the forwarding host via LMAP.
5.1.17 Factor 4.5 (17), Inter-Enterprise
When two organizations have teams which to communicate, the only
Internet Draft A Discussion of LMAP [Page 23]
Internet draft November 2003
requirement for LMAP is that it be implemented by the respective MTAs
and DNS servers. There is no additional cost or configuration
required to support cross-organizational teams.
6. Privacy Considerations
This proposal does not examine message contents, 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 network infrastructure, and traffic
analysis.
6.1 End Users
This proposal affects the privacy of end users in two ways. First,
it permits recipients to associate user identies or message contents
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 regrettable. 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 still do so 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.
We suggest that accountable methods of creating anonymity be used,
rather than unaccountable methods. One individuals desire for
anonymity does not, and should not, require the rest of the Internet
to accept large volumes of spam.
Internet Draft A Discussion of LMAP [Page 24]
Internet draft November 2003
6.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 yeild information about the network structure,
business relationships, and possibly the lifestyle of the domain
owner, as growing number of domains are owned by single people or
families.
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 announcement, 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.
6.3 Traffic analysis
Any LMAP aware MTA and DNS server requires additional network traffic
over ones which are not LMAP aware. This traffic may be analysed in
order to verify that two parties are communicating, or that a
particular message has been received. The additional traffic may
still be analysed in this manner, even if the SMTP session is
encrypted.
However, may MTAs already query MX and A records of a domain after
receiving a MAIL FROM command, so the thread of this new traffic is
minimal.
7. 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, implementors and administrators of systems using LMAP should
be aware of the issues raised herein.
8. Informative References
[1] Bradner, S., "The Internet Standards Process -- Revision
Internet Draft A Discussion of LMAP [Page 25]
Internet draft November 2003
3", BCP9, RFC 2026, October 1996.
[2] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[3] Crocker, D. "Technical Considerations for Spam Control
Mechanisms", work in progress, Internet-Draft
draft-crocker-spam-techconsider-00.txt, April 2003.
(Ed.: List other documents here. SMTP, SMTP AUTH, POP, SUBMIT, etc.)
9. Authors' Addresses
Alan DeKok (Editor)
IDT Canada, Inc.
1575 Carling Ave.
Ottawa, ON K1G 0T3
Canada
Email: [email protected]
Phone: +1 613 724 6004 ext. 231
Contributing Authors.
Raymond S Brand
P.O. Box 100486
Ft. Lauderdale, FL 33310
US
Email: [email protected]
Hadmut Danisch
Tennesseeallee 58
76149 Karlsruhe
Germany
E-Mail: [email protected]
Phone: ++49-721-843004 or ++49-351-4850477
Gordon Fecyk
Pan-Am Internet Services
24 - 482 Young Street
Winnipeg, MB R3B 2S6
Canada
Email: [email protected]
Phone: +1 204 292-9970
Richard W Rognlie
2782 Prince Harold Ct
Oak Hill, VA 20171
US
Internet Draft A Discussion of LMAP [Page 26]
Internet draft November 2003
Email: [email protected]
Laurence Sherzer
P.O. Box 5072
Deerfield Beach, FL 33442
US
Email: [email protected]
Meng Weng Wong
IC Group, Inc.
105 S 12TH ST STE 310
Philadelphia, PA 19107
USA
Email: [email protected]
Full Copyright Statement
Copyright (C) The Internet Society (2003). 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 27]