I recognize how hard it is to put together a spec: in no way do I
wish to belittle the work that went into this. But RFCs are forever.
(Please be assured I was at least this picayune with Dave and Doug's
drafts.)
OTOH, this was a lot of work. I don't think I'll review all the
other drafts so closely unless someone asks...
Internet-Drafts(_at_)ietf(_dot_)org <Internet-Drafts(_at_)ietf(_dot_)org> wrote:
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-marid-protocol-02.txt
Meng/Mark asked:
]
] In the interests of openness, rather than contacting the authors
] directly, please post to either:
] the ietf-mxcomp mailing list
] or
] the spf-discuss mailing list.
So, here goes:
] Abstract
] This document defines the format of a record that domains publish to
^^^^^^^
] authorize a set of hosts to send mail on its behalf...
^^^
grammatical mismatch.
] This document only describes the particulars of the syntax and the
] algorithm of the function.
I'd leave out the "only", and possibly add a few words to the next
sentence to clarify where the "semantics" are defined.
] 1. Introduction
] Owners of domain names publish SPF records to make declarations about
] hosts that are and are not permitted to use their domain names...
^^^^^^^^^
"Permitted" isn't a very helpful word here.
Granted, this is an "introduction", and we've already disclaimed any
intent to describe semantics; but I fail to see how "permitted" gives
the right connotations or denotations.
If we avoided the passive voice, and talked about "intend to permit"
to use their domain names, I think we'd be far better off.
We might also consider the word "authorize", though I'd strongly
recommend sticking within RFC2828 definitions of that word. BTW, we
might consider listing RFC2828 in the references...
] Mail receivers perform tests, which read published records to
] determine how a domain's declarations apply to particular hosts in
^^
] during mail reception.
^^^^^^
I think you mean just "during".
] 2. Permitted Sender Records
] ...
] record = version *( 1*SP ( directive / modifier ) ) *SP
I know the Table of Contents already mentioned ABNF being "collected"
in Appendix A; but I think it would make things easier if we mentioned
in the text here that the full ABNF description of the syntax is in
Appendix A, and that parts of it are quoted in the text which follows.
] 2.1.1 SPF DNS RR Type
] ...
] Sender-ID compliant mail originating zones MUST publish SPF2 type
] records, and MAY publish TXT type records that have identical content.
^^^
Perhaps we should warn folks about broken resolvers that won't be
able to retrieve SPF2 RRs: this text makes it sound as if the problem
is only finding DNS servers that correctly publish them.
] A Sender-ID compliant MTA MUST look up SPF2 RR type, it MAY lookup
^^^^^^^ ^^^^^^
We should try for consistency of spelling...
] TXT record at the same time, or wait for negative answer. SPF2 type
] SHOULD be used if available.
There's an implementation issue here: it's easy to imagine cases
where the TXT RR will arrive first, or even where the negative response
to the SPF2 query may never come. I think it would help to hint at this
issue.
] It is recognized that the current practice (using a TXT type record),
^^^^^^^^^^^^^^^^^^^^
A bad term, IMHO. RFCs are forever. I'd delete it, and replace the
parenthetical phrase with "using a TXT record" (without parentheses).
] Example RRs in this document are shown with the SPF2 record type,
] however they could be published with a TXT type.
^
Do you mean "also be published"?
] 2.1.3 Multiple Records
] A domain MUST NOT publish multiple records with the same version
] section, or with version sections that differ only in ver-minor or
] ver-ext fields. Such multiple records would cause a system checking
] them to select multiple records for processing and will result in a
] permanent error (see Section 3.4.1).
]
] Note that this rule still allows a domain to publish the same record
] twice, once as a TXT RR and once as a SPF2 RR, as only the SPF2 RR
] records will be considered.
I think the intent is to state that you may not publish two SPF2
records with the version string starting with "spf2." or two TXT records
starting with "spf2."; but that it is clearly OK to publish one SPF2
and one TXT (ignoring the issue of whether they must be identical).
I'm not sure that's what this text says.
Also, it's easy to imagine cases of a "minor" extension giving a
domain reason to publish different records to be interpreted by
receivers who are or are not updated to reflect the extension. We
should be clear whether we're forbidding such a practice.
You never specify what ver-ext should be used for. I think of it
as similar to SMTP extensions, but I may be far afield of the intent.
Since you seem to specify that its actual value must be ignored, I
must admit to being confused.
] 2.1.5 Multiple Strings
] Text DNS records (both TXT and SPF2 RR types) can be composed of more
] than one strings.]
^^^^^^^
Usual usage is "more than one string".
This section mainly (IMHO) deals with the feature where DNS servers
silently break a string into multiple substrings for purposes of
storing and reporting. I think it would be better to limit the text
to describing that practice and how to deal with it.
We certainly should not be encouraging people to advertise text
strings that would require they be split.
Also, this text as written tends to confuse multiple strings in a
single text-type RR with multiple RRs.
] 2.1.6 Record Size
] It is STRONGLY ENCOURAGED that published records remain small enough
] that query results will fit within 512 octets in order to keep DNS
] answers from falling over to TCP. Since the answer size is dependent
] on many things outside the scope of this document, it is only
] possible to give this guideline: If the combined length of the DNS
] name and the record text is under 480 characters, then DNS answers
] should fit in UDP packets.
This is not quite sufficient: _all_ records to be returned must fit
in the 480 bytes. (Since we seem to be headed for a situation in which
both SPF2 and SPF1 TXT records will be published for the same domain
name, this is not an academic quibble.)
] Nonetheless, Sender-ID compliant sites MUST use DNS recursive servers
] that support EDNS0 [RFC2671] and [RFC3226] in order to be able to
] receive large DNS RR sets
This language confuses. I think you mean Sender-ID receivers MUST
query DNS servers that support EDNS0 (DNS Extension Mechanisms), not
mentioning that they also must uses resolvers which support EDNS0 to
make those queries.
In any case, this is a capital-MUST, and I feel an obligation to
ask whether we really want to say that a sender or receiver is _not_
doing sender-ID if they don't <whatever>: personally, I would prefer
this MUST weren't there; but if we decide we want it, I think we
need to be _really_ clear what exactly MUST be done, and by which
parties to sender-ID.
] 2.1.8 Minor Version
] This document only specifies records with a minor version of "0".
] All published records MUST start with "spf2.0/pra".
]
] Future versions of this document may define other minor versions to
] be used.
This leaves me confused as to how we could manage a transition to
the next minor version. I recommend giving careful thought to that
expandability issue.
] 3.5.1 Term Evaluation
]...
] Mechanisms usually contain a ":" or "/" character after the name.
I suspect that, in the wild, mechanisms will more often be
specified without these.
Do you perhaps mean, 'most mechanisms allow a ":" or "/" ' ?
] 3.7 Domain Spec
] Several of these mechanisms and modifiers have a <domain-spec>
] section. The <domain-spec> string is macro expanded (see Section 7).
] The resulting string is the common presentation form of a fully
] qualified DNS name: A series of labels separated by periods. This
] domain is called the <target-name> in the rest of this document.
^^^^^^^^^^^^^
It's not clear to me whether <target-name> refers to the macro-
expanded version. (It seems it should, but this doesn't clearly
say so.)
] 4.2 "include"
There's a lot of room for confusion between "include" and "redirect".
If one looks long enough, it becomes clear that the basic difference
is that "include" returns, thus can generate only four conditions,
while "redirect" doesn't return, thus can generate all seven.
I think it would help to say so in as many words.
] The Include mechanism is intended for crossing administrative
] boundaries. While it is possible to use includes to consolidate
] multiple domains that share the same set of designated hosts, domains
] are encouraged to use redirects where possible, and to minimize the
] number of includes within a single administrative domain.
This text is particularly confusing. In fact, it _still_ confuses
me after multiple readings, and after I think I understand the
differences between "include" and "redirect".
Unless we can clarify just what point we're trying to make, I'd
recommend deleting it.
] 4.3 "a"
Here we get into serious IPv4 vs. IPv6 territory.
I assume that if <ip> is v4, one implements an "A" lookup, while
if <ip> is v6, one implements an "AAAA" lookup. It wouldn't hurt, IMHO,
to say so explicitly.
Also, since we _are_ aware of DNS servers which return incomplete
lists, it wouldn't (IMHO) hurt to hint at that -- at least to the
point of saying that <ip> is tested against the list returned.
(Personally, I am careful enough to go through the ABNF to find
just what "dual-cidr-length" means: not everyone will be. I don't
have a specific recommendation about this; but examples might help.)
] 4.4 "mx"
]...
] Then perform an A lookup on each MX name returned,
This is incorrect in the IPv6 case. (The grammatical structure also
doesn't match the previous sentence.)
I'm not enough of a DNS expert to remember for sure, but I think
resolvers are required to return A and/or AAAA RRs if they are known
and they fit. It wouldn't hurt to check the actual rule, and make
the text match the rule more closely.
] This behavior breaks with the legacy "implicit MX" rule. See
] [RFC2821] Section 5. If such behavior is desired, the publisher
] should specify an "a" directive.
^
I think you mean "also specify".
] 4.5 "ptr"
]...
] For each record returned, validate the host name by looking up its
] IP address.
Since this has known failure cases, we need to be quite explicit.
Fortunately, we're almost there in the pseudocode which follows.
IMHO, we should still clarify the v4/v6 issue; regardless, we're not
"looking up its IP address" -- we're doing an A or AAAA query and
searching the list returned.
] This mechanism matches if the <target-name> is an ancestor of the
] name of <ip>,
^^^^^^^^^^^^
I think you mean "validated host name".
] 4.6 "ip4" and "ip6"
] These mechanisms test if <ip> falls into a given IP network.
^^^^^^^^^^
I think you mean "is contained within".
] The <ip> is compared to the given network. If they match,
^^^^^^^^^^
Better to say "<cidr-length> high-order bits match".
] 5.2 exp: Explanation
]...
] If <domain-spec> is empty, or there are any processing errors,
] temporary (such as SERVFAIL) or permanent (such as NXDOMAIN), or if
] no records are returned, or if more than one record is returned, then
] the explanation string empty with no further computation.
^^^^^^^^^^^^^^^^^^^^^^^^
I'm not sure I know what you meant here...
] Note: During recursion into an Include mechanism, explanations do not
] propagate out.
^^^^^^^^^^^^^
I assume you mean that a "Fail", "SoftFail", or "Neutral" result
while recursed to an "include" mechanism should ignore the "exp="
modifier in the included SPF2 record and use the "exp=" modifier of
the outermost check_host(). Language to that effect, IMHO, belongs
under the "include" section, rather than here. (Or in addition; I
really don't care.)
It's less clear whether the "TempError" and "PermError" must
similarly ignore the "exp=" in the included SPF2 record. That, IMHO,
_needs_to_ be stated in the "include" section, as well as here.
] But during execution of a Redirect modifier, the explanation string
] from the target of the redirect is used.
^
I'd add:
" for a "Fail" result of a mechanism in the redirected record
Also, I think it would help to explicitly state whether the "exp="
modifier may be used for any other result.
] 6.1 Unrecognized Mechanisms and Modifiers
] New mechanisms can only be introduced by new versions of this
] document.
At first blush, I'd expect future versions of this document to
increment the <ver-minor>. But here, we run afoul of the requirement
(elsewhere) that there may not be two records which differ in
<ver-minor>.
This strikes me as a Catch-22: we can't publish for both old and
new versions of check_host() without publishing for both <ver-minor>s;
while we're prohibited from publishing one record for each.
While I _can_ wrap my mind about the idea that we have a <ver-minor>
field which MUST always be ignored, I'm having trouble wrapping my
mind around the idea that we MAY introduce new mechanisms, but all
receivers that haven't been updated yet MUST fail to evaluate our
SPF2 records in a useful way.
] 6.2 Processing Limits
]...
] MTAs or other processors MAY also impose a limit on the maximum
] amount of elapsed time to evaluate check_host().
This fails to make it clear whether the time limit applies:
- to the entire process, including all "include"s and "redirect"s;
- to all "include"s but separately to a "redirect";
- separately to all "include"s and "redirect"s;
If we want that to be a local option, we've got a problem trying
to guess which kind of limit the processor is imposing.
If we specify one of the above, the guessing is much easier, but
I'd still rather have an explicit error code for the timeout.
] Such a limit SHOULD allow at least 20 seconds. If such a limit is
] exceeded, the result of authentication SHOULD be "TempError".
This strikes me as a bad idea.
With "TempError", the default action (per core-3) is to reject with
" 450 4.4.3 Sender ID check is temporarily unavailable
The sender has no fully plausible alternative to simply retrying the
email, according to whatever schedule the sending MTA may have
programmed. Typically, this continues for days, possibly giving one
warning which usually says, "You do not need to retry," and offers
the user no mechanism for purging the queue.
However, the actual situation is likely to be that that particular
receiver chooses not to evaluate a record as complicated as the one
the submitter's domain has published. This information may _never_
reach anyone capable of resolving the issue; and in the meantime,
we're generating useless DNS traffic (which by definition exceeds
what the recipient is willing to handle).
] 7.1 Macro definitions
]...
] The uppercase versions of all these macros are URL-encoded.
Does this mean all macros, or just the three preceding ones?
] The "p" macro expands to the validated host name of <ip>.
]...
] There are two deprecated macro letters: "p" and "h".
I'm guessing you mean the first sentence overrides the second.
In any case, one of them should go, IMHO.
] 9. IANA Considerations
]...
] [[Missing application review policy]]
We need to specify at least the allocation method (e.g. first-come-
first-served).
] B.1 Simple Examples
]...
] spf2.0/pra mx/8 mx:example.org/8 -all
] -- any sending host in 192.0.2.128/24 or 192.168.2.136/8 passes
CIDR lengths are inconsistent. I'd rather not try to guess what was
intended...
--
John Leslie <john(_at_)jlc(_dot_)net>