On Sat, 25 Mar 2006, Frank Ellermann wrote:
Regarding over-restrictive domain specification the fixes are
toplabel = ALPHA / ALPHA *[ alphanum / "-" ] alphanum
; LDH rule (See [RFC3696])
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.
22.214.171.124 is a valid FQDN! But there is just that no "1" TLD is deligated
right now. What you're trying to do is assume that 126.96.36.199 is meant to be
ip address which may not be so.
"." at the end of FQDN is common convention when entering FQDN name as
used by dnsadmins.
name = ALPHA *( ALPHA / DIGIT / "-" / "_" / "." )
name = alphanum *( ALPHA / DIGIT / "-" / "_" / "." )
NAK. This is an incompatible change. As "name" suggests it
is something starting with ALPHA, excluding e.g. "numbers".
So explain to me again why number can not be a name?
(you know like "7 of 9" or short just "7"...)
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.
Ok, I'll ask Julian to put it on Council's agenda. Until it is decided
the changes are not in.
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
as many understand headers to mean header
| so, it SHOULD use the "Received-SPF" header defined here for each
^-- adding "field" here
| 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
| 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.
All those things you put "+1" for is what made it. This was simply cleaned up
version after I applied those changes.
be determined, which can be difficult to extract from headers.
Testing other than at the border is not recommended. ^-- guess
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" (?)
Ok, I'm applying your "the" to the changes too. In a few hours should have
list of proposed editorial changes on website in Julian's link.
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
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.
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