william(at)elan.net wrote:
Regarding over-restrictive domain specification the fixes are
as follows:
toplabel = ALPHA / ALPHA *[ alphanum / "-" ] alphanum
; LDH rule (See [RFC3696])
Change to:
toplabel = alphanum [ *[ alphanum / "-" ] alphanum ] [ "." ]
; LDH rule (See [RFC3696])
NAK. This is *_wrong_*. We want no trailing dot, and we need
"not only digits" to catch an erroneous IPv4 instead of FQDN
as syntax error. Don't screw with ABNF.
name = ALPHA *( ALPHA / DIGIT / "-" / "_" / "." )
to
name = alphanum *( ALPHA / DIGIT / "-" / "_" / "." )
NAK. This is an incompatible change. As "name" suggests it
is something starting with ALPHA, excluding e.g. "numbers".
Note that I'm not entirely sure,
No problem, I am. The ABNF as is MUST NOT BE TOUCHED WITHOUT
FULL COUNCIL REVIEW USING BILL'S ABNF VALIDATOR. I _scream_
Don't touch the ABNF. The ABNF as is is the result of _years_
of review and tuning, no subject for any last minute changes.
disallow name from ending in "-" or "_"
And no last minute "nice to have" features, who knows what's
out there in those millions (?) of published v=spf1 policies.
reduce this to:
4.5. Selecting Records
...
2. If any records of type SPF are in the set, then all records of
type TXT are discarded.
Yes, seconded, I can't tell if that's the only place, was there
a MUST somewhere ?
| It is RECOMMENDED that SMTP receivers record the result of SPF
| processing in the message headers. If an SMTP receiver chooses to do
^- this is actually ok but maybe a bit
confusing
as many understand headers to mean
header fields
+1
| so, it SHOULD use the "Received-SPF" header defined here for each
^-- adding "field" here
+1
| The Received-SPF header is a trace field (see [RFC2822] Section
^-- removed it
+1 (maybe also the "The" ?)
| 3.6.7) and SHOULD be prepended to existing headers, above the
^- making singular
+1 (adding "the")
| Received: header that is generated by the SMTP receiver. It MUST
| appear above any other Received-SPF headers in the message. The
^-- I sense tense error: above any <singular noun>
How about "above any other Received-SPF header field" ? There
can be two per MTA (one HELO and one MAIL FROM), so maybe I'm
wrong here.
| header has the format as follows:
| ^-- add field
+1 (more +1 for "header field" omitted)
7. The Received-SPF Header Field
No rewrite of a complete chapter, you can't be serious. I'm
also no fan of this beast, but now it exists, it's the first
new trace field since SMTP was invented, and we have to live
with it... <sigh /> Let the future PS tune it.
be determined, which can be difficult to extract from headers.
Testing other than at the border is not recommended. ^-- guess
what...
[...]
be determined, which can be difficult to extract from message header.
Testing other than at the border is not recommended.
Missing article "the message header" (?)
a simpler solution is to change title of the section (don't
forget to also do it in ToC) to be:
10.2. SPF-Authorized E-Mail May Contain Other False Identities
+1
12.2. The Received-SPF Mail Header
optionally change title to:
12.3. The Received-SPF Mail Header Field
No option, you want correct terminology, so let's be consequent.
Bye, Frank
-------
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