Re: [Asrg] Re: Documents for LMAP BOF
John Levine wrote:
I've made up two draft documents for the BOF, since neither Yakov and I
will be going.
a) LMAP overview, heavily reworked from the version that Alan wrote a
while ago. I took out all of the comparisons to now abandoned documents
and added a discussion of the relative merits of using IP, HELO/EHLO,
return path, and message header addresses as verification keys, and why
LMAP uses the return path.
Before starting in, one quick note: It would have been a lot easier to
compare this mechanically (i.e. diff -u) to the -00 draft if you had used
the same page-width as Alan did.
I have attached at the end of this message a diff of typo fixes.
In paragraph 1 of section 1.2, "Interpretation of LMAP Data", the range
should cover complete reliance on the data published in LMAP (making
accept/reject decisions solely on that basis) to complete ignorance
(non-implementation on the recipient side or not using the data to influence
the decision). I think the last sentence of that paragraph is entirely
Paragraph 2 is bluntly wrong. The intent of creating LMAP is that eventually
it WILL be used to reject mail, because it is assumed to be forged. A
comment like this belongs much later in the document, in a deployment
In section 2.2.1, "IP Address", paragraph 2, I disagree with equating MTA
Mark and LMAP. By design, they address different issues. MTA Mark addresses
usage that providers don't like and is for the use of IP-space owners. LMAP
addresses domain name abuse, and is for the owners of individual domain
names. Although the intersection between those 2 sets is large (all ISPs,
effectively), they are not equivalent.
OTOH, if your intent is really to generalize the concept embodied by LMAP,
that runs contradictory to your email, which reads "... and why LMAP uses
the return path." I have no objection to the generalization, but pick one,
I don't like how the comparison section phrases LMAP as a modification to
RFC 2821. I suspect that such wording will raise a lot of unnecessary
resistance to LMAP for no particular reason. I interpreted that part of RFC
2821 to mean that recipient MTAs should not reject mail on the basis of the
the HELO name not resolving to the connecting IP or the connecting IP not
reverse-resolving to the HELO name. Following this interpretation, LMAP
suggests neither, and thus is no modification to 2821, only an application
of the liberties of "local policy"-based rejections.
As I look that the rest of 2.2.*, I notice that 2.2.1 is excessively chatty.
Most of that should be in 2.2.5, "Comparison"
2.2.5, last paragraph: DATA payload headers are not particularly useful for
LMAP verification, because there are frequent enough circumstances in which
they will not verify for valid mail. They're also even more prone to RFC
2821 non-compliance than HELO and return path are.
None of 2.3 belongs in the problem statement and scope section. LMAP does
not address a problem in the DNS. Perhaps 2.3 should have been 3.1, and
titled "Reliance on DNS". There should be a big reference to the "Security
Considerations" section below in that, rather than spreading out such
The text in 2.3.1, "DNS Poisoning", has nothing to do with DNS poisoning
attacks. Have a look at <http://www.securityfocus.com/guest/17905>
The section headers under 3, "Common Concerns with LMAP", are ambiguous. In
reading carefully, it's clear that the section headers are the summary
responses, but it may be clearer if they were the common concerns
themselves, in quotes.
"3.1 LMAP Changes the end to end nature of the Internet"
"3.2 Roaming users are harmed by LMAP"
3.3, on Relaying and Forwarding, has more hand-waving than most of the rest
of this document.
First off, there are 2 separate circumstances to be dealt with. They may
have the same solution, but they should be described separately.
Here's how I would define them:
1. Relaying is a service provided to senders in which the relaying domain
agrees to deliver the sender's messages outside the relay's and sender's
In the relaying case, sender-rewriting is perfectly acceptable, as it means
there is another party who is at least as responsible for the message as the
sender, and is willing to accept that accountability. How the rewriting is
done and ensuring that bounces, DSNs, and the like get through is all a
matter of local policy and agreement.
2. Forwarding is a service provided to recipients in which the forwarding
domain agrees to deliver messages addressed to one mailbox to another mailbox.
The forwarding case is where the hand-waving comes in. Sender-rewriting is
undesirable here. It means that the intermediary recipient is essentially
forced to present themselves as accountable for a message that they have no
connection to. It also present a heavy burden on many users who use
something like pobox.com or ieee.org to forward to an ISP account where they
have no control over any whitelisting.
Regardless of the merits and usability of various sender-rewriting schemes,
there is massive potential for bad security and privacy without a lot of
Basically, I believe that we need to shift gears from practically mandating
sender-rewriting to making it clear that this is an open problem. This is
somewhere that I think general IETF input would be very useful.
3.4. Kiosks, etc., is somewhat glib about this issue. I've recently been
involved in discussions elsewhere on the major issues surrounding this.
There are a few problems and solutions. Again, I don't think recommending
this solution straight-off is the right way to handle it when we're putting
this before a large group of people who would most likely make very valuable
contributions to the discourse if it's clear that there's something to discuss.
If all of section 4 could be put in a table on a website somewhere, to make
it easier to digest, that may be useful.
The note on DNS reliance should mostly fall under Security Considerations,
as noted above.
The text acknowledging previous contributors has been removed.
b) a strawman "flexible sender verification" which basically squishes
DMP and a cut down version of RMX together, due to concerns from some
ISPs that want to do one lookup per domain, slurp up all the IPs for
that domain, and cache it, and other ISPs who want to do a simple DNSBL
style lookup for each message.
I will concur with Phill in that I don't think we need another rehash of
these ideas. At any rate, if we submit the discussion document for
consideration by the IETF, the implementation will be heavily discussed in
that realm anyway. There's no point in muddying the waters on this point,
and I think FSV does just that.
--- draft-irtf-asrg-lmap-discussion-01.txt 2004-02-07 21:25:37.000000000
+++ draft-irtf-asrg-lmap-discussion-02.txt 2004-02-07 21:31:36.000000000
@@ -170,7 +170,7 @@
a recipient would choose to accept that non-consensual mes-
- The method of eastablishing whether an IP address can send
+ The method of establishing whether an IP address can send
messages for a domain is similar to the usage of Dialup User
Lists (DUL) [ref: MAPS DUL]. With those methods, a network
provider publishes a list of IP addresses which have been as-
@@ -276,7 +276,7 @@
to pretend not to be a sender on a recipient's blacklist.
+o In account fraud, also known as ``phishing'', a sender poses
- as a person or organization with whom the receipient has a
+ as a person or organization with whom the recipient has a
business relationship, or would like to have a business re-
lationship. The sender does so in order to trick the recip-
ient into revealing personal information that the sender can
@@ -392,7 +392,7 @@
that the host at the connecting IP is authorized to use the
domain name it is offering. Like IP validation, HELO/EHLO
validation doesn't provide a contact e-mail address. The HE-
- LO/EHLO address shold be the host's name, such as MAIL.EXAM-
+ LO/EHLO address should be the host's name, such as MAIL.EXAM-
PLE.COM, even if the mail it sends all has addresses in the
domain EXAMPLE.COM. Although the address Postmaster(_at_)EXAM-
PLE.COM would exist, the address
@@ -403,7 +403,7 @@
mail since few hosts accept mail to domain literal addresses.
RFC 2821 permits the SMTP server to validate a domain address
provided to EHLO or HELO by doing a DNS lookup to see if the
- IP address matxhes, but does not permit the server to reject
+ IP address matches, but does not permit the server to reject
mail if the validation fails. HELO/EHLO-based LMAP would mod-
ify RFC2821 by allowing the server to reject mail based on HE-
LO/EHLO validation failure.
@@ -429,7 +429,7 @@
Although any or all of these items could be used for message
- validation, the LMAP propoals use the return path as a compro-
+ validation, the LMAP proposals use the return path as a compro-
mise between the best quality data and efficiency of opera-
tion. A verified return path, unlike IP or HELO/EHLO data, is
very likely to provide a specific responsible address and re-
@@ -530,7 +530,7 @@
Another concern raised about LMAP is that it will negatively
affect roaming users, that is, users not connected to their
- usual or home networ. The main concern of roaming users is
+ usual or home network. The main concern of roaming users is
that the deployment of LMAP will break the "end to end" nature
of the Internet.
@@ -585,7 +585,7 @@
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 propagation delays.
+ 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
@@ -700,7 +700,7 @@
Each of these proposals is a work in progress, hence the read-
er must refer to the latest defining document for each to
- learn the eaxct details of each. These comparisons are not
+ learn the exact details of each. These comparisons are not
intended to recommend one proposal over another, but rather to
highlight the differences among them.
@@ -877,8 +877,8 @@
Publication of LMAP information results in a readily available
list of IP addresses of hosts authorized to send messages as-
- sociated with a domain. These lists yeild information about
- the network structure, andbusiness relationships, and presents
+ sociated with a domain. These lists yield information about
+ the network structure, and business relationships, and presents
hostile parties with a list of targets to attempt to compro-