spf-discuss
[Top] [All Lists]

Re: [spf-discuss] Re: draft-schlitt-spf-classic AUTH48 review

2006-03-25 05:30:01

On Sat, 25 Mar 2006, Frank Ellermann wrote:

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.

1.1.1.1 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 1.1.1.1 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 / "-" / "_" / "." )
to
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 
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.

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 
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" (?)

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

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

ok.

--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net

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

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