In <419F038F(_dot_)4D75(_at_)xyzzy(_dot_)claranet(_dot_)de> Frank Ellermann
<nobody(_at_)xyzzy(_dot_)claranet(_dot_)de> writes:
wayne wrote:
Even the hints that SPF records must be published for the
domains used in the HELO/EHLO commands were removed.
| Domain owners must publish SPF records for the hosts that
| are use in both the MAIL FROM and HELO identities.
.........d
Your old wording was much more accurate (3. and 3.1):
| An SPF record declares which hosts are, and are not,
| authorized to use a domain name for the "HELO" or "MAIL FROM"
| identity.
[...]
| A domain name's SPF record is published in DNS. The record
| is placed in the DNS tree at the domain name it pertains to.
It's perfectly okay if domain owners publish sender policies
only for domains used in HELO, or only for domains used in
MAIL FROM. Of course that's only possible if these domains
are different.
Not that I used the lower case "must" not the upper case "MUST". No
where is anyone required to publish any SPF records.
The "SHOULD NOT rely on zone cut" is a bad idea, after all the
confusion (James still has a match_subdomains=yes in his text)
this thing needs to be nailed.
I agree, but since this is all about libspf2 doc right now, I'm not
going to try and deal with reaching a consensus with the SPF community
on this subject. That kind of thing would need to be done *if* there
is ever a revision to the draft-lentczner-spf-00 I-D. I haven't heard
from MarkL for a fair while now, and I haven't heard that he wants to
change anything.
What you really want is IMO a "SHOULD publish redundant sender
policies for subdomains used in HELO or MAIL FROM to avoid the
additional DNS lookups for the zone cut" (or similar).
Yeah, maybe that would be better. The next time I'm going over it,
I'll ponder it.
IPv4 over IPv6: Please mention the format, I vaguely recall
that it's trivial.
Yeah, it is trivial. I'll try to dig up the RFC that defines it. and
put an xref to it.
| During recursion into an "include" mechanism, exp= modifiers
| do not propagate out. But during execution of a "redirect"
| modifier, the explanation string from the target of the
| redirect is used.
That paragraph was always confusing, IMHO you could delete it.
Especially there's no "but", an explanation affects only the
final FAIL of the corresponding record. And a FAIL within an
"include" is never final, because it doesn't match.
I think this text was added due to the number of questions asked about
this. IMHO, the include: mechanism is really badly named. It should
be called something like if-pass:. It is too late now to fix it in
SPFv1, but maybe SPFv2.
How about replacing all LWSP by your own pretty FWS rule:
FWS = ([*WSP CRLF] 1*WSP) ; Folding white space
See my comments to Roger. This is probably a good thing to do if any
more cleanup on the Received-SPF header is desired.
In 4.5 the definition of %{d} vs. %{o} after the "zone cut"
case is still unclear, already reported in
<http://article.gmane.org/gmane.mail.spam.spf.discuss/12283>
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.
this document is *not* intended to be an official statement
of what SPF-classic is,
Sure, you'd need "IANA considerations" for the header,
Ok.
and 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.
I'm with Harry Katz, Jim Lyon and PHB on this one. I don't think the
SPF RR will ever be widely used and TXT will remain the primary method
of publish and checking SPF records for as long as SPF is used.
How is your "slash-magic" supposed to work ? My first guess:
As long as there is a dot (domain-end) or a % (macro-expand)
to the right of a slash (within the same term), this slash is
a part of the domain-spec. Otherwise it starts a cidr-length.
Or it's a delimiter within macro-expand followed by "}" later.
Basically, yeah. The ABNF requires backtracking, but that's an
unfortunate consequence of notation used in the SPF syntax.
Is that the moment where I should pray that ICANN never ever
creates a TLD different from your "." 1*ALPHA domain-end, or
is this guaranteed somewhere ? (Apparently not in RfC 1033)
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. If ICANN creates a TLD that ends in /[0-9]*, we are
screwed anyway.
-wayne