Subject: [spfbis] New Issue: Macro difficulties

From: Alessandro Vesely <[email-masked]>
Date: Tue, 04 Sep 2012 11:20:23 +0200

Section 8.1 *Macro Definitions*:

    s = <sender>
    l = local-part of <sender>
    o = domain of <sender>
    d = <domain>
    i = <ip>
    p = the validated domain name of <ip> (deprecated)
    v = the string "in-addr" if <ip> is ipv4, or "ip6" if <ip> is ipv6
    h = HELO/EHLO domain

It would be handy to add a reference to 20 pages backward:

   Where <ip>, <domain>, and <sender> are defined in [Section 4.1].

Section 8.1 is three-page long, and locating the definition of a macro
is difficult.  Sub-sections or hanging lists might help.

The "h" macro is missing a detailed description.  This macro seems to
be unique in that it keeps the same value irrespectively of the
identity being checked, whereas the values of "s", "l", and "o" change
as the identity changes.  (In previous messages I thought "o" behaved
like "h", sorry.)

Macro "h" is not exemplified in Section 8.2.  (A few cases for %{h}
and %{H} exist in the test suite, though.)

The last two paragraphs in Section 8.1 are notes that actually do
classify "s", "l", "o", or "h" as second-class macros, as far as
cacheability is concerned.

With respect to issue #22, "s", "l", and "h" allow to inject invalid
domains that can trigger PermError on otherwise correct SPF records.
We should add yet another note to state this point  --and warn either
the publisher or the developer, depending on how we solve catch #22,
e.g. any record that uses "s", "l", or "h" isn't really correct ;-)

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 04 Sep 2012 18:35:19 -0400

> e.g. any record that uses "s", "l", or "h" isn't really correct ;-)

I think this concern would be easiest to deal with if you provided a diff for 
the intended text.

Scott K