Julian Mehnle wrote:
Everyone who can spare the time, please read through the draft (see the
first URL above) one last time as thoroughly as you can and report soon
any errors you find!
Sorry to admit, this is my first time reading this doc. And it's very
impressive. 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.
Geoff
[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