ietf-asrg
[Top] [All Lists]

Re: [Asrg] Re: Documents for LMAP BOF

2004-02-07 20:27:23
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.

    http://www.taugh.com/draft-irtf-asrg-lmap-discussion-01.txt

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 unnecessary. 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 considerations section.

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, please.

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 discussion. 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.
E.g.:
"3.1 LMAP Changes the end to end nature of the Internet"
"3.2 Roaming users are harmed by LMAP"
etc.

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
domains.
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 implementation consideration. 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.
      http://www.taugh.com/draft-levine-fsv-00.txt

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.

Philip Miller
--- draft-irtf-asrg-lmap-discussion-01.txt      2004-02-07 21:25:37.000000000 
-0500
+++ draft-irtf-asrg-lmap-discussion-02.txt      2004-02-07 21:31:36.000000000 
-0500
@@ -170,7 +170,7 @@
    a recipient would choose to accept that non-consensual mes-
    sage.
 
-   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 
Postmaster(_at_)MAIL(_dot_)EXAMPLE(_dot_)COM
@@ -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-
    mise.