wayne wrote:
[both the MAIL FROM and HELO identities]
Not that I used the lower case "must" not the upper case
"MUST". No where is anyone required to publish any SPF
records.
Yes, but it's still not true that domain owners "must" publish
policies for all their possible HELO and MAIL FROM domains.
It's perfectly okay if they publish a sender policy only for
those domains where they really want it. Maybe say "should"
if it's in one sentence with "both".
this is all about libspf2 doc right now
This month. In December it's the only input for the "council",
and minus some details "we" (tinw) apparently all agree that
it reflects the real SPF as close as possible, and it's based
on the last I-D.
*if* there is ever a revision to the draft-lentczner-spf-00
The name is irrelevant, actually I was surprised that it wasn't
draft-mengwong-spf-02. If both Mark and Meng don't want their
name on it use your name or somebody else, all (s)he has to do
is to take a document backed by a majority of the SPF council,
and send it mailto:internet-drafts AT ietf.org
IMHO, the include: mechanism is really badly named
Most definitely, but as you say too late for v=spf1.
It should be called something like if-pass:
Yes, or on-pass:. BTW, your idea to transform redirect= into a
mechanism doesn't work unfortunately, the best I found for this
idea was "all" with a domainspec, but it's still weird. What
with the +/-/~/? in a redirect-mechanism replacing redirect= ?
[FWS]
See my comments to Roger. This is probably a good thing to
do if any more cleanup on the Received-SPF header is desired.
Yes, use [FWS] where you want to allow spaces, use FWS where
you want at least one space, and copy the FWS definition from
RfC 2822 minus the obsolete "obs-FWS".
In 4.5 the definition of %{d} vs. %{o} after the "zone cut"
case is still unclear
[...]
The zone cut says where to fetch the SPF record. It says
nothing about changing all the other variables. Therefore,
the other variables aren't changed.
That's not intuitive. Normally %{o} is the "original" domain
as found in HELO resp. MAIL FROM, and %{d} is the "domain" of
the currently evaluated record. Without "zone cut" they are
initially identical, until check_host() calls itself for an
include: resp. redirect=.
With your rule %{d} would be _different_ from the domain of the
evaluated SPF record if found in conjuction with a "zone cut".
Even if that's what your implementation does I don't think that
that's what it should do. E.g. in the example "%{d} explains:"
used as disclaimer for explanations, it would be wrong to say
"www.claranet.de explains:" instead of "claranet.de explains:".
(www.claranet.de has no policy, the "zone cut" is claranet.de).
the consensus was to use the new SPF RR in all examples
(hiding the old TXT RR for various and not only technical
reasons).
I recall no such consensus for SenderID, let alone for
libspf2.
Sure, I was talking about the last SPF I-D (= draft-lentczner).
Of course you haven't implemented a SPF RR yet, it has to be
assigned by the namedroppers or whoever decides this (IANA ?).
What has "Sender ID" to do with the SPF RR ? "Sender ID" is a
broken proprietary scheme, it was never near to any consensus.
I'm with Harry Katz, Jim Lyon and PHB on this one.
You're in bad company.
I don't think the SPF RR will ever be widely used
Read my lips, "not only technical reasons". Saying it louder
here would give it away.
TXT will remain the primary method of publish and checking
SPF records for as long as SPF is used.
Sooner or later there will be enough (ab)uses of TXT, and then
it stops to work without a new RR. The first thing breaking
with multi-TXT-abuses are wildcards. You find it in your memo,
grep "512" draft-schlitt-spf-01.txt
The ABNF requires backtracking
As long as it's unambiguous, context-free, and correct I don't
care, The RfC-editor won't accept an ambiguous grammar, they
check (or at least they say so in RfC 3716 ;-)
[dubious domain-end 1*ALPHA]
I don't know of any guarantee, but I strongly suspect that
the idea that TLDs are alpha only is already encoded in so
many programs that they never will.
While looking for RfC 3716 I stumbled over RfC 3696:
| The LDH rule, as updated, provides that the labels (words or
| strings separated by periods) that make up a domain name must
| consist of only the ASCII [ASCII] alphabetic and numeric
| characters, plus the hyphen. No other symbols or punctuation
| characters are permitted, nor is blank space. If the hyphen
| is used, it is not permitted to appear at either the
| beginning or end of a label. There is an additional rule
| that essentially requires that top-level domain names not be
| all-numeric.
A label as defined in 1035 is good enough for your domain-end,
it starts with a letter. Anything which excludes dot, slash,
space, and percent should work for the purpose of domain-end,
1*ALPHA is less than you need.
Bye, Frank