Re: [ietf-dkim] New Issue: protecting a domain name vs. protecting a domain tree
Dave, I'm not understanding how the algorithm can work if you omit step 2 from section 4.2.2. It can't. Without step 2 there is nothing example.com can do to protect its name space. Right again. It would be a large mistake to remove step 2. Arvel ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Issue: protecting a domain name vs. protecting a domain tree
Dave, So I guess what we're talking about is to what coverage ADSP gives you. There are three options, not two: 1. The name itself, and nothing more. 2. The name itself plus one level down in the subtree. 3. The name itself plus all levels below it in the subtree. The current draft gives you option 2. As a side effect, it acts like option 3 for names that do not exist, e.g., given the name a.b.example.com, and assuming that b.example.com does not exist, then a.b.example.com gets covered as a side effect of the fact that b.example.com does not exist. I disagree with your assertion that this hasn't been explicit. As others have pointed out, 5016 section 4.2 already states this. It would make sense to make this explicit in the ADSP draft itself, but that's a matter of wordsmithing, not a question of the desirability and appropriateness of the function in the first place. For the record, I'm in favor of leaving step 2 in. I think it is appropriate, in scope, and desirable for both senders and receivers alike. eric ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Issue: protecting a domain name vs. protecting a domain tree
On Apr 9, 2008, at 11:43 AM, MH Michael Hammer (5304) wrote: In response to the question Dave asks, I like the idea of providing the option of protecting an entire (sub)tree within in a domain. My question to the gurus is whether there is a clean way to identify main domains below a TLD. For the generics this would appear to be straight forward. For country TLDs I'm not so sure. Some country TLDs might always require a .co.TLD or .edu.tld (or something similar). Not only is there inconsistency across such TLDs, there may be inconsistency over time as far as requirements within a TLD. What started me thinking along this line was allowing a base domain (if you will) to make an assertion that ALL subdomains only send signed mail (or never sign mail or ?) Technically, Dave Crocker is right. The issue he raises is valid since message content is independent of SMTP. When taken to heart, one can not expect _any_ DNS records relate to what might be email- addresses contained within the messages. One simple assertion can overcome this issue. Declare protections afforded by ADSP _only_ relate to email-addresses exchanged using SMTP. With this statement, there would be MX or A DNS resource records required by the domain. Presence of these records therefore offers a means to validate the domains. To put an upper limit on the number of policy related DNS transactions that could increase over time, require publishing MX records with any SMTP policy record. This would place an upper limit on the number of transactions needed to determine presence of SMTP policy. The first step in evaluating SMTP policy would be requesting an MX record. To determine whether the domain might be valid for SMTP, a subsequent transaction could check for A records. Until A record discovery becomes deprecated, and to avoid tree walking, domains seeking protection should be required to publish ADSP records at every node there is also A records. The existence of policy records in the absence of MX records would also refute any message comes from the domain. As policy records would need to be published in conjunction with A records, the requirement that policy be qualified by MX records eliminates any need to also publish bogus MX records as have been suggested as an alternative strategy. Acceptance of messages independent of SMTP delivery is separate matter not covered by ADSP. This could be handled through a scope statement in the ADSP record, but this field is currently missing. The way forward would be to declare that ADSP pertains to SMTP exchanged messages. When handling a mixture of messages exchanged using SMTP and other protocols, there will be potential conflicts. When the exchange protocol is not apparent to recipients, these messages may be seen as not complaint with ADSP assertions when a default assumption of SMTP is used. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Issue: protecting a domain name vs. protecting a domain tree
Dave, I'm not understanding how the algorithm can work if you omit step 2 from section 4.2.2. Suppose that example.com wants to assert to the world that it signs all messages. It will create an ADSP record for example.com with the appropriate assertion. Without step 2, all an attacker has to do is to craft a message purported to be from [EMAIL PROTECTED] (where thing is not a valid label in the example.com domain). Step 1 fails, because of course there is no _adsp._domainkey.some.thing.example.com (i.e., it returns NXDOMAIN), so the algorithm falls through to the next step, which is now step 3. Step 3 searches for _adsp._domainkey.thing.example.com, which also returns NXDOMAIN, so the algorithm terminates with a result indicating that no ASP record was present --- and the absence of an ADSP record means that unsigned mail must be deemed legitimate. Without step 2 there is nothing example.com can do to protect its name space. If that's what you mean when you say that presumes the goal of protecting an entire sub-tree then I'm all for protecting the entire sub-tree. Anything less looks to me like it severely weakens the entire point of ADSP. eric --On April 7, 2008 2:32:25 PM -0700 Dave Crocker [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Like others I am guessing that you are referring to section 4.2.2 step 2. Yup. Since the domain doesn't exist the administrator can't have been expected to create a policy for it so error seems like the right answer to me. That presumes the goal of protecting an entire sub-tree. Absent that goal, the goal is to cover domains that have ADSP records. Very different scope of effort. Otherwise to create policies for all of my domains I would have to create policies not just for all existing sub-domains of that domain (which I personally would support) but all conceivable sub-domains of a domain (which I don't think I would). Again, creating records for every conceivable name -- and no, I can't imagine any reasonable administrator attempting that -- is only an issue if there is a belief that ADSP can 'protect' all names in a sub-tree. d/ ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Issue: protecting a domain name vs. protecting a domain tree
Eric Allman wrote: Dave, I'm not understanding how the algorithm can work if you omit step 2 from section 4.2.2. Suppose that example.com wants to assert to the world that it signs all messages. It will create an ADSP record for example.com with the appropriate assertion. Without step 2, all an attacker has to do is to craft a message purported to be from [EMAIL PROTECTED] Eric, Actually from your note, it looks to me that you understand just fine. It looks as if the question is covering a single-name vs. a sub-tree. Your note mostly takes sub-tree as an implicit given, but then states it explicitly at the end. The attack that you describe requires using some name other than the one that is listed. The single, specific name that is listed is, indeed, protected. If that's what you mean when you say that presumes the goal of protecting an entire sub-tree then I'm all for protecting the entire sub-tree. Anything less looks to me like it severely weakens the entire point of ADSP. (Aside: Folks keep correcting my own use of the word protect for DKIM or ADSP and given the delicate balancing act that ADSP must walk, I think their concern is quite reasonable. So I'm trying to switch over to say cover...) You echo the word goal. That certainly seems like the right starting point. Does the working group assert the goal of covering entire sub-trees? Note that this isn't in the working group charter, the requirements statement, or even explicitly stated in the specification. That does not make the goal inappropriate, but it does mean that it needs to be stated and confirmed explicitly. (And certainly the specification needs to state this explicitly and clearly.) But frankly that's the easy part. Because we then we have the small question of what are the technical requirements and details, for covering a sub-tree adequately, within the DNS, when using an underscore sub-naming scheme? Given that the DNS is not designed to permit this conveniently and, in fact, does not seem to me to be able to do it at all, we certainly need a complete and coherent technical description of how ADSP accomplishes complete coverage of a sub-tree. This would describe the approach being taken for covering a sub-tree, and the component mechanisms being used to achieve it -- Step 2 is but one of those components. It would also demonstrate what kind of attacks it protects against. I am not aware of any previous technology providing such sub-tree functionality, and so this ought to be subject to careful review by the DNS and Security folks. At that, I fear it will nonetheless warrant a status of experimental. So in terms of a goal I'm probably in agreement that it would be dandy to do. But I think that my desiring that goal is pretty much irrelevant. The problem is that I believe there is no technical means of covering a subtree completely, except by case-analysis, which isn't covering a tree at all. I believe the Step 2 query only makes sense for ADSP in the context of covering an entire sub-tree, but that ADSP does not describe the larger framework into which Step 2 fits, for accomplishing that goal. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Issue: protecting a domain name vs. protecting a domain tree
Dave, 1402 and 1534 were specifically mentioned and discussed in Philly in Jim's presentation http://www3.ietf.org/proceedings/08mar/slides/dkim-0.pdf. In fact, between the two they've been discussed at multiple meetings.We know this because the mechanism has changed over time and was presented as it changed. You can continue to traipse through the minutes of previous meetings (my own recollection and the minutes confirm http://www.ietf.org/proceedings/07mar/minutes/dkim.txt that is that the group spent time on this very issue in Prague). You did not object. My own recollection of the Prague discussion was that we specifically considered the positives and negatives of tree walking as well as a domain existence query, but perhaps the audio i lying around if you want to go to more detail. Putting aside that procedural issue, the fundamental basis for your concern is that there are two independent systems that have no basis for interdependency. But your premise is false, and the issue is specifically raised in the current -03 draft, here: 2. _Verify Domain Exists._ The host MUST perform a DNS query for a record corresponding to the Author Domain (with no prefix). The type of the query can be of any type, since this step is only to determine if the domain itself exists in DNS. This query MAY be done in parallel with the query made in step 2. If the result of this query is an NXDOMAIN error, the algorithm MUST terminate with an appropriate error. NON-NORMATIVE DISCUSSION: Any resource record type could be used for this query since the existence of a resource record of any type will prevent an NXDOMAIN error. MX is a reasonable choice for this purpose is because this record type is thought to be the most common for likely domains, and will therefore result in a result which can be more readily cached than a negative result. No A record required, as Frank and I mentioned earlier. Perhaps I have missed some text that you are referring to. Could you correct me? Eliot ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Issue: protecting a domain name vs. protecting a domain tree
Eliot, I am trying to be careful and specific in the things I am posting, here, and you and others need to be the same. My goal is to get discussion going. Yours appears to be to stop it. Unfortunately, that has often been at the root of problems in this working group. Let me repeat the bottom line, once again: There is nothing in the mailing list archive that demonstrates working group rough consensus on the matter of extending ADSP's scope to include more than a single, exact-match name. The record *does* contain discussion about the problems with attempting this expanded scope. So please stop repeating broad references that turn out to be invalid or off the point. The substantiation for this assessment is in the remainder of this message... Eliot Lear wrote: 1402 and 1534 were specifically mentioned and discussed in Philly in Jim's presentation http://www3.ietf.org/proceedings/08mar/slides/dkim-0.pdf. 1402 Duplicate of 1534Applicability of SSP to subdomains The above text contains the only reference to either of the documents in Jim's slides. To the extent that it proves discussion took place, it is content free. And let's get very clear about something: I did not say there was no discussion. So your proving that discussion took place in Philadelphia is not the issue. In fact, between the two they've been discussed at multiple meetings.We know this because the mechanism has changed over time and was presented as it changed. Since I didn't claim otherwise, I'm not sure what your point is. In any event, it would be nice to see documentation of the details in such discussion and what it's conclusions were. But most importantly we need to see documentation of consensus on the mailing list. You do not address this fundamental IETF requirement. And by address I mean point to specific details that provide confirmation. Generic document references don't help, particularly when it turns out that they do not prove your point. You can continue to traipse through the minutes of previous meetings (my own recollection and the minutes confirm http://www.ietf.org/proceedings/07mar/minutes/dkim.txt that is that the group spent time on this very issue in Prague). 1. For perhaps the third time: the minutes do not contains the strings 1402 or 1534. The only reference to tree is: Discussion focuses on subdomains, wildcards, tree-walking. While, yes, it's entirely reasonable to take that as proof that something was said, it does not provide any content. In particular, it doesn't even describe the claimed conclusions. You did not object. My own recollection of the Prague discussion was that we specifically considered the positives and negatives of tree walking as well as a domain existence query, but perhaps the audio i lying around if you want to go to more detail. Concerns about sub-tree details have been expressed repeatedly and broadly over the months. Whether I, in particular, voiced them in Philadelphia, seems to be a rule you are attempting to enforce as meaningful and I can't guess why. Putting aside that procedural issue, the fundamental basis for your concern is that there are two independent systems that have no basis for interdependency. I'm pretty sure that what I said does not strictly map to your characterization of it. Were you attempting to engage in constructive dialogue, rather than shut this thread down, the question of its equivalence or difference strikes me as potentially useful for improving everyone's understanding of the issue. So it's a shame that you have chosen to take such an adversarial stance. But your premise is false, and the issue is specifically raised in the current -03 draft, here: Qouting an entire passage always feels comforting. However I do not see which bits of text are on point or how. To the extent that your own comment is meant to clarify this: No A record required, as Frank and I mentioned earlier. my constantly referring to A record probably is, indeed, distracting. I'm happy to substitute all of my references to A with NXDOMAIN. I believe it does not change any of the technical, administrative or operational concerns I raised. Perhaps I have missed some text that you are referring to. Could you correct me? I don't understand what you are asking for. Text that says what? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Issue: protecting a domain name vs. protecting a domain tree
I'm going to see whether we can actually have some constructive dialogue in this thread, by posting a message responding to a point that Eliot raised in a message that had a different focus: Dave Crocker wrote: 3. At least one of the sub-tree mechanisms is attempting to glean information from the absence of publisher action. Let me explain: ... c) Checking for the presence of an A record is intended to try tell you something in the absence of an explicit action by the domain owner. That's it's flaw: It is intuiting ADSP information from non-ADSP action. While there is nothing wrong with checking the A record, it's semantics have literally nothing (directly) to do with ADSP. (and, for completeness, please modify the above: s/ A / NXDOMAIN /.) Eliot said: the fundamental basis for your concern is that there are two independent systems that have no basis for interdependency. The semantics of a non-ADSP DNS record certainly were not intended to be relevant to ADSP. And I doubt anyone is going to claim that non-ADSP DNS records were created for the purose of ADSP use. Whether ADSP can reasonably extract some semantics is an entirely reasonable line of question. What we need to see is discussion and consensus that it can and does and that the benefits outweighs the costs. An nice example of a counter-argument is: Wietse Venema wrote: The problem is that valid email origin is a subset of all the names that resolve in the DNS. In other words, there are false positives in the algorithm that continues when [any DNS] record lookup succeeds. One interpretation of this point is that the presence of a DNS entry (that is, a 'failure' to get an NXDomain) might be meaningful, but the scope of its meaning is much broader than ADSP. Once again: A mechanism possibly worth pursuing, but outside of ADSP. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Issue: protecting a domain name vs. protecting a domain tree
Dave Crocker wrote: Whether ADSP can reasonably extract some semantics is an entirely reasonable line of question. Right. And that's the basis on which Barry and I think this worth discussing again. What we need to see is discussion and consensus that it can and does and that the benefits outweighs the costs. An nice example of a counter-argument is: Wietse Venema wrote: The problem is that valid email origin is a subset of all the names that resolve in the DNS. In other words, there are false positives in the algorithm that continues when [any DNS] record lookup succeeds. One interpretation of this point is that the presence of a DNS entry (that is, a 'failure' to get an NXDomain) might be meaningful, but the scope of its meaning is much broader than ADSP. I'm not following that. Can you give an example? Even if its partly speculative, it'd help me understand your point. (And in this case, I guess speculation as to future uses of DNS might be valid, since the current absence of entries is what we're proposing to use.) Stephen. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Issue: protecting a domain name vs. protecting a domain tree
Stephen Farrell wrote: One interpretation of this point is that the presence of a DNS entry (that is, a 'failure' to get an NXDomain) might be meaningful, but the scope of its meaning is much broader than ADSP. I'm not following that. Can you give an example? Even if its partly speculative, it'd help me understand your point. (And in this case, I guess speculation as to future uses of DNS might be valid, since the current absence of entries is what we're proposing to use.) DKIM and ADSP fit into a larger framework of filtering activities. I hope there is nothing controversial about that assertion. It means that there are many analyses and tests that are outside the scope of DKIM (and ADSP). Some filtering engines query for an NXDOMAIN today, independent of DKIM or ADSP. That's a pretty clear indication that its meaning and utility are not tied to ADSP. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Issue: protecting a domain name vs. protecting a domain tree
Stephen Farrell wrote: Dave Crocker wrote: Whether ADSP can reasonably extract some semantics is an entirely reasonable line of question. Right. And that's the basis on which Barry and I think this worth discussing again. Sorry, I should have said a basis above. Its been pointed out to me that Dave's concern is broader than just the above which is fair enough. S. What we need to see is discussion and consensus that it can and does and that the benefits outweighs the costs. An nice example of a counter-argument is: Wietse Venema wrote: The problem is that valid email origin is a subset of all the names that resolve in the DNS. In other words, there are false positives in the algorithm that continues when [any DNS] record lookup succeeds. One interpretation of this point is that the presence of a DNS entry (that is, a 'failure' to get an NXDomain) might be meaningful, but the scope of its meaning is much broader than ADSP. I'm not following that. Can you give an example? Even if its partly speculative, it'd help me understand your point. (And in this case, I guess speculation as to future uses of DNS might be valid, since the current absence of entries is what we're proposing to use.) Stephen. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Issue: protecting a domain name vs. protecting a domain tree
Dave Crocker wrote: Stephen Farrell wrote: One interpretation of this point is that the presence of a DNS entry (that is, a 'failure' to get an NXDomain) might be meaningful, but the scope of its meaning is much broader than ADSP. I'm not following that. Can you give an example? Even if its partly speculative, it'd help me understand your point. (And in this case, I guess speculation as to future uses of DNS might be valid, since the current absence of entries is what we're proposing to use.) DKIM and ADSP fit into a larger framework of filtering activities. I hope there is nothing controversial about that assertion. It means that there are many analyses and tests that are outside the scope of DKIM (and ADSP). Some filtering engines query for an NXDOMAIN today, independent of DKIM or ADSP. That's a pretty clear indication that its meaning and utility are not tied to ADSP. All that seems clear. I guess however, it still doesn't help me with (an example of) why ADSP making a query and reacting to an NXDOMAIN response as currently spec'd may be problematic. I think the logic for the WG not wanting ADSP to be able to expliticly state no mail was correct, but that this case seems different, hence the request for an example. S. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Issue: protecting a domain name vs. protecting a domain tree
Date: Mon, 7 Apr 2008 14:32:25 -0700 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] CC: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] New Issue: protecting a domain name vs. protecting a domain tree [EMAIL PROTECTED] wrote: Like others I am guessing that you are referring to section 4.2.2 step 2. Yup. Since the domain doesn't exist the administrator can't have been expected to create a policy for it so error seems like the right answer to me. That presumes the goal of protecting an entire sub-tree. Absent that goal, the goal is to cover domains that have ADSP records. Very different scope of effort. I think I would describe my goal more narrowly than that. I don't think that any ADSP record should be protecting anything more than the exact domain the record is entered for. I also think it is worthwhile for it to be possible for a domain administrator to be able to cover everything within his administrative control with their own records if they want to do that. The case we're talking about here is not whether or not it is worthwhile to protect the whole domain sub-tree but what to do when encountering something that is definitionally NOT part of the domain sub-tree (remember we're talking about NXDOMAIN cases here only, not intuiting anything about any actual domains). Since these things are not domains then saying that searching for a domain policy for them returns an error seems entirely reasonable to me. Robert _ Use video conversation to talk face-to-face with Windows Live Messenger. http://www.windowslive.com/messenger/connect_your_way.html?ocid=TXT_TAGLM_WL_Refresh_messenger_video_042008___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Issue: protecting a domain name vs. protecting a domain tree
All that seems clear. I guess however, it still doesn't help me with (an example of) why ADSP making a query and reacting to an NXDOMAIN response as currently spec'd may be problematic. There is absolutely nothing in the least bit problematic about an NXDOMAIN query. If Dave wants this functionality removed he must build and demonstrate a constituency willing to support him. To do that he'll need to provide a great deal more justification for change than he has thus far. My own belief is that everybody is persuaded that this document has been discussed to death and that sufficient compromise has been made on all sides of the various issues. The document is fine like it is. Let's get to last call and move on. Arvel ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Issue: protecting a domain name vs. protecting a domain tree
Barry Leiba wrote: Eliot Lear said the following: By my recollection, this topic alone has been discussed at at least two - and possibly three - working group meetings. Please advise. This topic has definitely been discussed a number of times. The focus of my note wason the contents of the specification, not on previous discussion. I'll repeat that distinction: The current draft does not deal with exact-name vs. sub-tree issues as an explicit point of distinction; it has bits of each scattered around. As such, the specification is, at best, confusing on the distinction, nevermind incomplete on the tree construct. But with respect to the working group's history of discussing this topic I'll first thank Eliot for citing the recently-closed Issue. It was quite instructive to go back and read the associated mailing list thread. I strongly encourage others also to do read that thread http://mipassoc.org/pipermail/ietf-dkim/2006q4/006377.html since I think it substantiates my concerns, rather than resolves them: 1. The cited thread shows a complete lack of anything one might call consensus. 2. The cited thread pretty much shows a complete lack of coherence. 3. I have no idea what the basis was for the chairs declaring the matter resolved. This is an inherent problem with closing items by fiat and without explanation. Bottom lines: a. There is a difference between having discussed something and having resolved it. b. The current draft is, at best, confusing about the distinction of exact vs. tree c. There is no technical means for doing a clean, efficient and thorough job of protecting a sub-tree, when using the DNS. It wasn't designed for that use and it doesn't handle it for scenarios such as DKIM needs. Consequently, it is not surprising that the current specification's component mechanisms for protecting a sub-tree are partial, at best. The particular point in Dave's note that troubles me, and that I don't think we have agreement on, is his third one: 3. At least one of the sub-tree mechanisms is attempting to glean information from the absence of publisher action. Let me explain: ... c) Checking for the presence of an A record is intended to try tell you something in the absence of an explicit action by the domain owner. That's it's flaw: It is intuiting ADSP information from non-ADSP action. While there is nothing wrong with checking the A record, it's semantics have literally nothing (directly) to do with ADSP. I agree with that assessment, but more importantly, I think the working group doesn't yet agree on whether he's right or not. Right about what? There is a factual assertion that an existing A record will have been created for reasons other than ADSP. That's a statement of fact, not opinion. A records are not created for any purpose having to do with ADSP. If someone disagrees with the statement of fact, they need to substantiate it. And, yes, if they force such an exercise, I'll substantiate my assertion of objective fact. Since the A record is not created for ADSP, how can its semantics have anything to do with ADSP? Again, this is in the realm of objective fact, not opinion or preference. So I'm unclear what the working group could disagree with. (I'm concerned that we are in the realm of operating on the basis that the working group could formulate a consensus that 2+2=5 and the fact that there is consensus would resolve the matter.) So, Barry, please clarify what you mean by the working group doesn't yet agree on whether he's right or not. So let's clear this up with a focused discussion that gets one of the following results: * We have consensus that ADSP should explicitly say that in the absence of an ADSP record you have no information, and you treat the message as you did before DKIM/ADSP existed. Any other processing might be proposed as an extension, in another document. I believe I understand this choice. * We have consensus that there IS a well-defined process that we recommend following in the absence of an ADSP record, and that having the ADSP document define this is within scope for the base document. I am pretty sure I do not understand this alternative, but I'm pretty sure it does not respond to the concerns I raised. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Issue: protecting a domain name vs. protecting a domain tree
Dave, I'll repeat that distinction: The current draft does not deal with exact-name vs. sub-tree issues as an explicit point of distinction; it has bits of each scattered around. As such, the specification is, at best, confusing on the distinction, nevermind incomplete on the tree construct. Can you suggest wording? But with respect to the working group's history of discussing this topic I'll first thank Eliot for citing the recently-closed Issue. It was quite instructive to go back and read the associated mailing list thread. I strongly encourage others also to do read that thread As a matter of fact the way the issue was resolved was through Jim Fenton's presentation at the last IETF, and not so much through online discussion. This having been said, the chair's have spoken and I won't delve further into why I think that issue should remain resolved. http://mipassoc.org/pipermail/ietf-dkim/2006q4/006377.html since I think it substantiates my concerns, rather than resolves them: 1. The cited thread shows a complete lack of anything one might call consensus. That's because the consensus was formed at the meeting, as the minutes and Jim's presentation shows. Be sure to look at those too. Eliot ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Issue: protecting a domain name vs. protecting a domain tree
Eliot Lear wrote: Dave, I'll repeat that distinction: The current draft does not deal with exact-name vs. sub-tree issues as an explicit point of distinction; it has bits of each scattered around. As such, the specification is, at best, confusing on the distinction, nevermind incomplete on the tree construct. Can you suggest wording? Let me nip this in the bud: No. I believe the entire effort to do more than deal with an exact-match names is a mistake and that all component details that attempt to expand the scope should be removed from the specification. So the suggested wording I would offer is to remove text from the specification, not add it. 1. The cited thread shows a complete lack of anything one might call consensus. That's because the consensus was formed at the meeting, as the minutes and Jim's presentation shows. Be sure to look at those too. I seem to recall that decisions are not made at working group meetings. They are made on the mailing list. So I'd be curious for a citation on the mailing list where the consensus from the meeting was reviewed and confirmed. d/ ps. Yes, this is all painful. It is also a good lesson about why being careful with process is particularly important for topics that are complex and poorly understood. -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Issue: protecting a domain name vs. protecting a domain tree
Since the Chairs have ruled that this warrants yet further discussion... Dave Crocker wrote: Folks, This issue encompasses some others, but I believe it is more basic and therefore informs the others and therefore needs to be resolved separately: There is a basic difference between trying to protect a single domain name, versus trying to protect an entire sub-tree. Two comments: (1) It's worth being careful about the word protect; the draft doesn't use it (except once, in a somewhat different context) and we should be careful about setting an expectation that publication of ADSP confers protection. There is benefit to the publisher that may be viewed as protection that comes from the use of ADSP information by verifiers, but it is indirect and only to the extent that ADSP records are retrieved and used. (2) ADSP does not publish information about entire subtrees, only about domains and labels within an immediate domain. 1. The DNS was not designed with sub-tree operators. The wildcard mechanism is a very narrowly-defined capability and is useless in the face of underscore-based naming, since the underscore node really defines an attribute of the domain name it is under, rather than defining a true name. What this leaves us with is attempting to invent mechanisms that turn out to do only a partial job, at best. Underscore-based names have no special standing within DNS (such as definition of attributes), other than the fact that they are illegal as hostnames but are legal for some other purposes. DNS wildcards are indeed useless in the face of name prefixes, which is why ADSP does not depend on nor use them. The mechanism described in the draft may be viewed as doing a partial job but we still need to consider whether what it does is useful. I believe it is. 2. Some of the sub-tree effort is for administrative convenience. Some is for expanded semantics. It's not clear that the specification is clear about this distinction. It is not clear that the specification is clear about the motivations that make it mandatory to add sub-tree mechanisms to the specification. Again, I reject the premise that this a sub-tree mechanism. What are the expanded semantics to which you refer? 3. At least one of the sub-tree mechanisms is attempting to glean information from the absence of publisher action. Let me explain: I believe the desire with checking the A record is similar to the idea behind having ADSP in the first space. That is: a) DKIM is for declaring the presence of an accountable identity. If a signature is present, you know something. If it is absent, you know nothing extra. b) ADSP attempts to tell you something, in the absence of a signature. It does that by defining something else that must be present. If the ADSP record is present, you know something. If it is absent, you know nothing extra. c) Checking for the presence of an A record is intended to try tell you something in the absence of an explicit action by the domain owner. That's it's flaw: It is intuiting ADSP information from non-ADSP action. While there is nothing wrong with checking the A record, it's semantics have literally nothing (directly) to do with ADSP. ADSP is not checking the A record, as others have pointed out. -Jim ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Issue: protecting a domain name vs. protecting a domain tree
On Apr 7, 2008, at 8:33 AM, Eliot Lear wrote: Barry: 3. At least one of the sub-tree mechanisms is attempting to glean information from the absence of publisher action. Let me explain: ... c) Checking for the presence of an A record is intended to try tell you something in the absence of an explicit action by the domain owner. That's it's flaw: It is intuiting ADSP information from non-ADSP action. While there is nothing wrong with checking the A record, it's semantics have literally nothing (directly) to do with ADSP. I agree with that assessment, but more importantly, I think the working group doesn't yet agree on whether he's right or not. As Frank points out, that's not what the draft says. The draft says that you can pick *any* record. The purpose is simply to determine whether the domain exists. The argument is semantically different, particularly when you discuss this in terms of the recommended query, an MX record. The worst you can say is that there is an interdependency between the deployment of MX records and ADSP records in the very same domain. The only reason you have to do the query is because of the additional labels applied. If you want to get away from this you need to use a new RR. This could be generalized as a domain spoofing issue. Before SMTP receivers expend resources validating signatures, a check of the originating domain's validity eliminates the expenditures of validating signatures for domains that otherwise are determined invalid through the lack of inbound SMTP servers. Protecting resources is not a trivial matter, as DKIM demands more of receivers. Querying any record may not be conclusive. When either network providers or domains themselves inject synthesized wildcard records, sub-domains unrelated to valid message email addresses will appear to exist. To prevent this situation from being exploited, specific checks for MX or A resource records indicate at least possible support of SMTP servers by the domain. The recommendation in issue 1547 simplifies this test. Without MX resource records being found, receivers could conclude ADSP records below the '_adsp.' prefix do not exist either. While DKIM is not limited to SMTP, the purpose for ADSP seems related to the spoofing of SMTP message sources. After all, methods of message exchange involving prior arrangements are unlikely benefited by ADSP. As such, ADSP should stipulate this limitation as this would better ensure proper use. It seems some aspect of this concern appears to have been closed in issue 1551. The tracking note only indicates 'resolved' by the Philly meeting consensus. There is nothing within the minutes indicating what discussion took place or what aspect of this issue had been resolved or rejected. While MUA related protocols may be used in conjunction with SMTP, the public exchange of messages using SMTP is where ADSP offers benefit. If messages from sources other than those initially from SMTP are to be covered by ADSP, is there a list of these initial non-SMTP message sources? Such a list could permit a review of ADSP's impact on these different protocols. The introduction and even details related SMTP error codes seem to indicate ADSP is a mechanism intended to operate in conjunction with messages initially exchanged by SMTP, and then secondarily through MUA related protocols. What problem would be created by making a statement that ADSP is intended to benefit messages initially exchanged using SMTP? -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Issue: protecting a domain name vs. protecting a domain tree
-Original Message- From: [EMAIL PROTECTED] on behalf of Barry Leiba Sent: Mon 4/7/2008 9:58 AM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] New Issue: protecting a domain name vs. protecting a domain tree Eliot Lear said the following: By my recollection, this topic alone has been discussed at at least two - and possibly three - working group meetings. Please advise. This topic has definitely been discussed a number of times. And Stephen and I have discussed Dave's note from today, and think it's appropriate to continue the discussion a bit. We need to keep it focused and come to a clear conclusion -- the problem is that we don't think we really have agreement on this question. The particular point in Dave's note that troubles me, and that I don't think we have agreement on, is his third one: 3. At least one of the sub-tree mechanisms is attempting to glean information from the absence of publisher action. Let me explain: ... c) Checking for the presence of an A record is intended to try tell you something in the absence of an explicit action by the domain owner. That's it's flaw: It is intuiting ADSP information from non-ADSP action. While there is nothing wrong with checking the A record, it's semantics have literally nothing (directly) to do with ADSP. I agree with that assessment, but more importantly, I think the working group doesn't yet agree on whether he's right or not. So let's clear this up with a focused discussion that gets one of the following results: * We have consensus that ADSP should explicitly say that in the absence of an ADSP record you have no information, and you treat the message as you did before DKIM/ADSP existed. Any other processing might be proposed as an extension, in another document. * We have consensus that there IS a well-defined process that we recommend following in the absence of an ADSP record, and that having the ADSP document define this is within scope for the base document. Yes, this discussion is in scope for now. Let's keep the discussion on track, and resolve this quickly. Barry, as DKIM working group chair ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html Barry, slight modification * We have consensus that ADSP should explicitly say that in the absence of an ADSP record you have no information, and you treat the message as you did before DKIM/ADSP existed. We need to stop there as the rest of the sentence could include checking the credit score of a domain's owner as an DKIM/ADSP extension which may have value for an implementation but not a consensus document describing the value of a policy/practice. thanks, Bill Oxley ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Issue: protecting a domain name vs. protecting a domain tree
Eliot Lear wrote: As a matter of fact the way the issue was resolved was through Jim Fenton's presentation at the last IETF, and not so much through online discussion. OK. So I have now also reviewed: 1. Issue 1534 and its associated thread: https://rt.psg.com/Ticket/Display.html?id=1534 2. Minutes from Philadelphia 3. Jim Fenton's slides from Phili 4. The mailing list archive since Philadelphia What I find is absolutely nothing that deals with any of the points I raised. And by deals with I mean contains substance. Certainly the thread associated with 1534 shows no consensus and not much focus. Jim's slide have nothing on the topic, other than a listing of one of the two relevant Issues, and the Phili minutes do not make mention of this issue at all. And I find nothing in the mailing list archive that discusses it. Since it is not possible to prove a negative, I'm going to again have to ask that those asserting that this matter was discussed and resolved need to document it. And I mean point to concrete materials that confirm the claim, in both referenced Issues, that the matter was resolved. As for the very reasonable requests that I clarify how the issue I am raising is different from the two cited Issues, here's my best effort: 1. There has been no requirement stated, carefully discussed, and clearly resolved, that ADSP must deal with a sub-tree or anything other than a single domain name. What seems to have happened, for some, is a de facto assumption that it is requires. However it is not in the charter and it is not in the requirements. No mailing list discussion (and I will claim no face2face meeting) has discussed this requirement carefully and to resolution. 2. There is a difference between specifying component mechanisms, versus discussing concepts and approaches that motivate those mechanisms. The current specification contains no clear statement of what it is trying to do, with respect to covering implicit or subordinate (or superior) names. 3. The DNS does not permit covering multiple names competently, for uses such as ADSP is attempting. Any effort by ADSP to compensate for this deficiency must be, at best, partial and probably also experimental. Previous working group discussions in this area -- including those cited as Issue 1402 and Issue 1534 -- have at most mentioned the higher level issues of trying to covering more than a single domain name. However they have not discussed the conceptual distinction, nor have they discussed or resolved the requirement, nor have they resolved basic technical limitations. If someone needs more explanation that distinguishes this Issue that I am raising and what has come before, they need to provide some detail. That's because the consensus was formed at the meeting, as the minutes and Jim's presentation shows. Be sure to look at those too. Which of his slides shows this? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Issue: protecting a domain name vs. protecting a domain tree
a) DKIM is for declaring the presence of an accountable identity. If a signature is present, you know something. If it is absent, you know nothing extra. b) ADSP attempts to tell you something, in the absence of a signature. It does that by defining something else that must be present. If the ADSP record is present, you know something. If it is absent, you know nothing extra. c) Checking for the presence of [any DNS] record is intended to try tell you something in the absence of an explicit action by the domain owner. That's it's flaw: It is intuiting ADSP information from non-ADSP action. To clarify a perhaps overlooked point: the existence of [any DNS] record for the Originator domain does NOT imply that it is a valid email origin. If the record is absent, then we know nothing that the absence of the ADSP record for that domain didn't already tell us. Any suggestion to the contrary is probably a mistake. While there is nothing wrong with checking [any DNS] record, it's semantics have literally nothing (directly) to do with ADSP. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Issue: protecting a domain name vs. protecting a domain tree (#1534)
Dave Crocker wrote: it is not in the requirements JFTR: http://tools.ietf.org/html/rfc5016#section-4.2 Deployment Consideration 2: Subdomain Coverage | Thus, it would be advantageous for SSP to not | only cover a given domain, but all subdomains | of that domain as well. I'm unhappy with some points in RFC 5016, and I still have enough of all sub-domain issues after the efforts in 2004, but the topic is mentioned in RFC 5016. /JFTR Which of his slides shows this? I see no #1534 in the nine IETF 71 PDF pages, and no 1534 in the jabber log. #1543 was discussed. Frank ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Issue: protecting a domain name vs. protecting a domain tree
Date: Sun, 6 Apr 2008 23:06:25 -0700 From: [EMAIL PROTECTED] To: ietf-dkim@mipassoc.org Subject: [ietf-dkim] New Issue: protecting a domain name vs. protecting a domain tree 3. At least one of the sub-tree mechanisms is attempting to glean information from the absence of publisher action. Let me explain: I believe the desire with checking the A record is similar to the idea behind having ADSP in the first space. Dave, Like others I am guessing that you are referring to section 4.2.2 step 2. In that step it explicitly says that you can check for any record you want and the semantics of the returned record itself are basically irrelevant only the existence of some response other than NXDOMAIN matters. In the case of an NXDOMAIN I didn't read that section as intuiting any policy. It just says to return an error which I read as something different than, return some specific result. Since the domain doesn't exist the administrator can't have been expected to create a policy for it so error seems like the right answer to me. Otherwise to create policies for all of my domains I would have to create policies not just for all existing sub-domains of that domain (which I personally would support) but all conceivable sub-domains of a domain (which I don't think I would). Robert _ Pack up or back up–use SkyDrive to transfer files or keep extra copies. Learn how. hthttp://www.windowslive.com/skydrive/overview.html?ocid=TXT_TAGLM_WL_Refresh_skydrive_packup_042008___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Issue: protecting a domain name vs. protecting a domain tree
Siegel, Ellen wrote: Jim, in your presentation to the ESPC you brought up the fact that one reason to encourage sub-domains to publish 'unknown' ADSP records was so that they wouldn't inadvertently inherit an ADSP record from a parent domain. As long as such inheritance is possible, i.e. that a subdomain can automatically inherit from a parent domain, it must be true that we're discussing subtrees. There is an important difference. The subtree of example.com includes everything ending in .example.com such as a.example.com, b.example.com, and even f.e.d.c.b.a.example.com. ADSP does not cover the subtree; it covers only labels in the immediate example.com domain. If we retain that capability, inadvertent or not, in the spec, I think we need to call it out explicitly and discuss how to counter it. There are two ways to counter that capability: either the subdomain publishes an ADSP record, or the parent domain publishes its ADSP record with the t=s flag as described in section 4.2.1 (or, conceivably, both). Another possibility, I suppose, is to apply an Author Signature to the message which makes ADSP irrelevant as long as it isn't broken. However, I agree with Dave that it may be cleaner to just exclude the possibility of inheritance rather than try to deal with the fallout. It's not cleaner for a domain that wishes to publish ADSP and has thousands of hostnames in the same domain now faces the prospect of publishing thousands of ADSP records, and doesn't have tools to automate this process. My comment at ESPC was that I believe it would be a Best Practice for Coalition members to routinely publish, or have published, explicit ADSP records for domains that they send from. -Jim ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Issue: protecting a domain name vs. protecting a domain tree
Wietse Venema wrote: a) DKIM is for declaring the presence of an accountable identity. If a signature is present, you know something. If it is absent, you know nothing extra. b) ADSP attempts to tell you something, in the absence of a signature. It does that by defining something else that must be present. If the ADSP record is present, you know something. If it is absent, you know nothing extra. c) Checking for the presence of [any DNS] record is intended to try tell you something in the absence of an explicit action by the domain owner. That's it's flaw: It is intuiting ADSP information from non-ADSP action. To clarify a perhaps overlooked point: the existence of [any DNS] record for the Originator domain does NOT imply that it is a valid email origin. If the record is absent, then we know nothing that the absence of the ADSP record for that domain didn't already tell us. Any suggestion to the contrary is probably a mistake. ADSP is doing the converse of that: it takes the non-existence of [any DNS] record for the Author Domain as an implication that it is NOT a valid email origin, or more accurately reports if that is the reason there isn't an ADSP record for that domain. -Jim ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Issue: protecting a domain name vs. protecting a domain tree
On Apr 7, 2008, at 2:01 PM, Jim Fenton wrote: Siegel, Ellen wrote: As long as such inheritance is possible, i.e. that a subdomain can automatically inherit from a parent domain, it must be true that we're discussing subtrees. There is an important difference. The subtree of example.com includes everything ending in .example.com such as a.example.com, b.example.com, and even f.e.d.c.b.a.example.com. ADSP does not cover the subtree; it covers only labels in the immediate example.com domain. When the policy record below _adsp.example.com contains a parameter that precludes validity for sub-domains below example.com, then it must be expected this is being used. If we retain that capability, inadvertent or not, in the spec, I think we need to call it out explicitly and discuss how to counter it. There are two ways to counter that capability: either the subdomain publishes an ADSP record, or the parent domain publishes its ADSP record with the t=s flag as described in section 4.2.1 (or, conceivably, both). Another possibility, I suppose, is to apply an Author Signature to the message which makes ADSP irrelevant as long as it isn't broken. Sub-domain coverage concerns _how_ policy records are discovered when _not_ published within sub-domains containing email-address with either none or invalid signatures. However, I agree with Dave that it may be cleaner to just exclude the possibility of inheritance rather than try to deal with the fallout. It's not cleaner for a domain that wishes to publish ADSP and has thousands of hostnames in the same domain now faces the prospect of publishing thousands of ADSP records, and doesn't have tools to automate this process. This can be resolved by qualifying possible valid domains with the existence of resource records needed to discover SMTP servers. This limits the instances where ADSP records are need to those nodes that contain SMTP discovery resource records. My comment at ESPC was that I believe it would be a Best Practice for Coalition members to routinely publish, or have published, explicit ADSP records for domains that they send from. In that case, there is no need for ADSP. Change the ADSP draft to simply say use ESPC data to ascertain DKIM signature requirements. Perhaps ADSP draft should change into a standard format for this data. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Issue: protecting a domain name vs. protecting a domain tree
Wietse Venema wrote: a) DKIM is for declaring the presence of an accountable identity. If a signature is present, you know something. If it is absent, you know nothing extra. b) ADSP attempts to tell you something, in the absence of a signature. It does that by defining something else that must be present. If the ADSP record is present, you know something. If it is absent, you know nothing extra. c) Checking for the presence of [any DNS] record is intended to try tell you something in the absence of an explicit action by the domain owner. That's it's flaw: It is intuiting ADSP information from non-ADSP action. To clarify a perhaps overlooked point: the existence of [any DNS] record for the Originator domain does NOT imply that it is a valid email origin. If the record is absent, then we know nothing that the absence of the ADSP record for that domain didn't already tell us. Any suggestion to the contrary is probably a mistake. Jim Fenton: ADSP is doing the converse of that: it takes the non-existence of [any DNS] record for the Author Domain as an implication that it is NOT a valid email origin, or more accurately reports if that is the reason there isn't an ADSP record for that domain. The problem is that valid email origin is a subset of all the names that resolve in the DNS. In other words, there are false positives in the algorithm that continues when [any DNS] record lookup succeeds. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Issue: protecting a domain name vs. protecting a domain tree
Wietse Venema wrote: Wietse Venema wrote: a) DKIM is for declaring the presence of an accountable identity. If a signature is present, you know something. If it is absent, you know nothing extra. b) ADSP attempts to tell you something, in the absence of a signature. It does that by defining something else that must be present. If the ADSP record is present, you know something. If it is absent, you know nothing extra. c) Checking for the presence of [any DNS] record is intended to try tell you something in the absence of an explicit action by the domain owner. That's it's flaw: It is intuiting ADSP information from non-ADSP action. To clarify a perhaps overlooked point: the existence of [any DNS] record for the Originator domain does NOT imply that it is a valid email origin. If the record is absent, then we know nothing that the absence of the ADSP record for that domain didn't already tell us. Any suggestion to the contrary is probably a mistake. Jim Fenton: ADSP is doing the converse of that: it takes the non-existence of [any DNS] record for the Author Domain as an implication that it is NOT a valid email origin, or more accurately reports if that is the reason there isn't an ADSP record for that domain. The problem is that valid email origin is a subset of all the names that resolve in the DNS. In other words, there are false positives in the algorithm that continues when [any DNS] record lookup succeeds. That's true; that's why the result from ADSP in this case is, or should be, Unknown. But I don't see that in the spec; it simply indicates that no ADSP record was present, and the spec isn't giving enough guidance about what to do in that case. In ssp-01, it had said non-suspicious in this case, and apparently this got lost when suspiciousness was removed. Thanks for spotting that. -Jim ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Issue: protecting a domain name vs. protecting a domain tree (#1534)
Frank Ellermann wrote: I see no #1534 in the nine IETF 71 PDF pages, and no 1534 in the jabber log. #1543 was discussed. As I noted in http://mipassoc.org/pipermail/ietf-dkim/2008q1/009713.html , issue #1534 fell through the cracks when I was preparing my slides for Philadelphia and was not discussed. I had suggested that it not be closed without the opportunity for some discussion. -Jim ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Issue: protecting a domain name vs. protecting a domain tree (#1534)
Jim Fenton wrote: As I noted in http://mipassoc.org/pipermail/ietf-dkim/2008q1/009713.html , issue #1534 fell through the cracks when I was preparing my slides No problem, for the known reasons I (try to) stay out of sub-domain discussions. Swapping steps 1 and 2 in 4.2.2 might make sense: If an author-domain does not exist looking for an ADSP is pointless, result nxdomain is bad enough. Frank ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
