Frank Ellermann wrote:
Somebody posted
a short list with nits a few days ago here, made all sense -
purely editorial stuff.
This may have been my list, noticed, it seemed, only by Frank.
I will repeat it here, not because these nits are all that important, but
because the document itself is excellent and also because a couple of these
are a bit "political" and we don't at this stage want to get up anyone's
nose
unnecessarily.
By the way, my take on:
When a mechanism is evaluated, one of three things can happen: it can
match, it cannot match, or it can throw an exception.
is to write <<it can not-match>>. I vaguely remember this being suggested
ages ago about when this awkward sentence first appeared. There was a time
when "can-not" was the spelling, so we might here be coining a useful new word!
Geoff
And here is my "short list":
. I noted a couple of nits,
some of which are probably noted elsewhere (I didn't check), some not
relevant to AUTH48 and some
you won't agree with! My suggestions are within <<>>. Only one is really
an "error" as I see it, the solecism
on page 7.
[Page 6]
Treating "Neutral" more harshly than "None" will <<would>> discourage
domain owners from
testing the use of SPF records (see Section 9.1)
[Page 7]
The domain believes the host is not authorized but
is not willing to make that strong of a statement.<<such a strong
statement>>
[Page 8]
This is the same whether the TXT or SPF RR type is used.
<<SPF RR has not been introduced at this stage of doc>>
When publishing via TXT records, beware of other TXT records
published there for other purposes. They may cause problems with
size limits (see Section 3.1.4).
<<Seems soft, given the intense debate about SPF (re)use of TXT.
Perhaps: "respect other TXT records ...., and note that there may be
problems ..."
It seems disingenuous to suggest that it is the pre-existing records
which are causing the problem!>>
[Page 9]
(either TXT and <<or> SPF RR types)
[Page 14]
Modifiers are not mechanisms:<<;>> they do not return match or
not-match. <<Definitely a nit!>>
[page 21]
The result of this new evaluation of check_host() is then considered
<<to be>> the result of the current evaluation with the exception that
if no.
[Page 22
"%{i} is not one of %{d}'s designated mail servers."
-- a message with a little more info <<information>>, including
the IP address
that failed the check
[Page 29]
Whereas <<Although>> the reasons for
changing the reverse-path are many and long-standing, SPF adds
enforcement to this requirement.
[Page 31]
Service providers that offer mail services to third-party domains,
such as sending of bulk mail, may have to <<want to>> adjust their
setup in light
[Page 34]
This could include returning "Pass" for an <ip> value
where the actual domain's record would evaluate to "Fail". See
[RFC3833] for a description of the <<delete "the">> DNS weaknesses.
-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com