Stuart D. Gathman wrote:
It is not all clear that your interpretation of the museum case has
any concensus. The RFC doesn't say anything explicit either.
So far I didn't note that anybody disputes that some TLDs have IPs
for whatever reason, and that they are of course FQDNs. As far as
RFC 4408 is concerned it clearly says in 4.8/1:
Several of these mechanisms and modifiers have a <domain-spec>
section. The <domain-spec> string is macro expanded (see Section 8).
Obviously %{h} matches <macro-expand> in <domain-end>, and therefore
<domain-spec> after an empty <macro-string> consisting of zero parts.
The resulting string is the common presentation form of a fully-
qualified DNS name: a series of labels separated by periods.
TLDs are in the common presentation form of labels separated by dots,
as there's only one label there's of course no separating dot.
This domain is called the <target-name> in the rest of this document.
In other words the <target-name> is "museum" (or rather "test") in
hello-museum-1, and "test." in hello-museum-2. There's no proviso to
fix the trailing dot issue in a <target-name> I'm aware of.
Actually that should be tested too, %{h}%{h} is testtest for "test"
but test.test. for "test.".
You'll need additional zonedata e12.example.com with a:%{h}%{h} and
test.test. with the relevant IP. Get FAIL for helo: test (because
testtest has no IP) but PASS for helo: "test." (test.test. IP match).
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/?list_id=735