Mark Lentczner wrote:
An IETF Internet Draft URL is stable for six months or more.
But that's no reason to keep remaining typos until April 12 ;-)
Stuff found in a side-by-side diff with another text. all line
numbers as in draft-lentczner-spf-00.txt:
Typo near line 706:
- determined by and the local policies of the receiver. (see Section
+ determined by the local policies of the receiver. (see Section 2.4)
---
Typo near line 903:
- do, then check_host() exits with a result of "PermFail".
+ do, then check_host() exits with a result of "PermError".
---
Typo near line 1133:
- in "in-addr.apra." if the address is an IPv4 one and "ip6.arpa." if
+ in "in-addr.arpa." if the address is an IPv4 one and "ip6.arpa." if
---
Typo near line 1640:
- validate host name the string "unknown" is used.
| validated host name the string "unknown" is used.
---
Space in exp= problem near line 1572:
- Your spam volume has increased by 581%
- is incorrect. Instead, say
- Your spam volume has increased by 581%%
+ Your spam volume has increased by 581%
+ is incorrect. Instead, say
+ Your%-spam%-volume%-has%-increased%-by%-581%%
The macro-string-with-sp construct proposed in another text is
also possible to fix this problem, but please find a shorter
name for it (if you use it).
---
Another minor change (not a typo) in the other text is the
handling of DNS errors in PTR directives near line 1149:
+ <target-name>, this mechanism fails to match. If a DNS error occurs
+ while doing the PTR RR lookup, then this mechanism fails to match.
+ If a DNS error occurs while doing an A RR lookup, then that host name
+ is skipped and the search continues.
That addition was prepared near line 993:
- DNS queries, if the DNS server returns an error (RCODE other than 0
+ DNS queries, except where noted, if the DNS server returns an error
---
Another PTR clarification near line 1167 can't hurt:
- its hosts.
+ its hosts and that the "ptr" mechanism is one of the last mechanisms
+ checked.
---
Potential typo near line 935:
- are legal in a DNS label, for example, the space or control
+ are legal in a DNS label, for example, the control characters.
Actually I'm not sure what that's about, maybe it's irrelevant.
---
The handling of "unknown mechanisms" in the other text makes
sense, but I didn't check all syntactical details. First of
all it allows to delete lines 1410..1429. Instead of the
"unknown-mechanism" you'd need a similar "unknown-modifier".
With this trick any "unknown-mechanism" like 'foo' is a syntax
error, no more well-formed 'foo' versus an invalid 'k$'.
---
The other text also proposes to remove all sub-classes of FAIL
(replaced by PermError in some relevant cases). That addresses
among other issues my problem with MAIL
FROM:<user(_at_)[1(_dot_)2(_dot_)3(_dot_)4]>
while talking with 1.2.3.4
It also addresses the S in SPF as "Sender" policy, so if the
receiver doesn't like MAIL FROM:<user(_at_)[1(_dot_)2(_dot_)3(_dot_)4]>, then
that's
his decision, but it has nothing to do with the "S" in SPF.
The other text uses the following statement instead of a "FAIL"
with reason "malformed domain" near lines 367 resp. 749:
+ If the <domain> is not an fully qualified domain name, check_host()
+ immediately returns the result "None".
Probably that should be "... a fully ....". As always I love
succesful attempts to implement KISS, let's get rid of these
confusing FAIL subclasses. Near line 367 it is:
- malformed in a valid SMTP transaction. In these cases, check_host()
- is defined in Section 4.3 to return a Fail result.
+ malformed in a valid SMTP transaction. In these cases, check_host()
+ is defined in Section 4.3 to return a "PermError" result.
For more modifications look for "malformed" (e.g. delete lines
736..744, and modify/delete three "550" examples near 430..433).
---
The other text introduces a "default explanation" in addition
to the empty string. That's probably a matter of taste, either
check_host() can add a disclamer like "%d explains" to whatever
explanation offered by a 3rd party, or the caller handles this.
But check_host() can obviously evaluate this kind of disclaimer,
that's not necessarily true for the caller (%d can be tricky).
Therefore the proposed "default explanation" makes sense, the
empty string isn't needed to indicate "no explanation by a 3rd
party". Let check_host() do it all. Do we need a separate
chapter for this kind of check_host() "configuration" ? It's
also relevant for the evaluation of a %{r} = domain of receiver.
---
One interesting detail in the other text near line 631:
+ other TXT records published at the domain name. Records that are too
+ long to fit in a single 512 UDP packet MAY be silently ignored.
If I understad this correctly this clause allows to ignore all
sender policies requiring TCP instead of UDP. And/or it allows
simple buffer allocation strategies. Whatever it does, it's
better than a potential TOAST ;-)
Bye, Frank