spf-discuss
[Top] [All Lists]

Re: Re: It's published!

2004-10-17 12:07:13
In <41728E44(_dot_)65FD(_at_)xyzzy(_dot_)claranet(_dot_)de> Frank Ellermann 
<nobody(_at_)xyzzy(_dot_)claranet(_dot_)de> writes:

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:

Thank you for extracting all the typos and such that I fixed in
draft-schlitt-spf-00.  The credit for finding most of these goes to
Roger Moser.  Thanks Roger!

---
Typo near line 1640:
-  validate host name the string "unknown" is used.
|  validated host name the string "unknown" is used.

Thanks, fixed.

---
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).

Requiring %- for spaces in explanation TXT RRs would be a huge
incompatiblity with the install base.  I strongly suspect that this is
just a case of an unintended bug being introduced when fixing other
draft bugs.

I welcome suggestions for a better name than macro-string-with-sp.
The name looks ugly in the spec, but has no other affect.  It was
late.  I wasn't feeling creative.


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.

Domain names have always been able to have a space character via the
%- escape.  This is true in spf-draft-200406 and in
draft-lentczner-spf-00. 

---
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$'.

Maybe I'm missing something here, but does any of this comment also
apply to draft-schlitt-spf-00*?


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 ....".

Fixed, thanks.

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 ;-)

Yes, this text allows receivers to ignore DNS over TCP.  The text that
I originally sent to Meng had a bunch of verbage about how there being
many existing firewalls that incorrectly block TCP port 53.  So, even
if the receiver *wants* to allow longer records, they may unknownly be
blocking them.

By making it clear to domain owners that their long SPF records *may*
be ignored, it will encourage them to keep them short.

This verbage also allows receivers to not have to accept 64k SPF
records and the equivalent DoS problems that comes along with that.
draft-spf-lentczner and spf-draft-200406 both require receivers to
accept such records if they want to remain compliant with the draft.


-wayne


<Prev in Thread] Current Thread [Next in Thread>