Holm, Mark wrote:
Neither the SenderID or SPF Classic specs are sufficiently
pointed about the argument of an a: mechanism being
preferably a domain name and not an IP address.
In draft-mengwong-spf-01.txt you find in section 4.4:
| A = "a" [ ":" domain-spec ] [ dual-cidr-length ]
And later in the collected ABNF (appendix A) you find:
| domain-spec = domain-name / macro-string
| domain-name = domain-part *( "." domain-part ) [ "." ]
| domain-part = as defined in [RFC1034]
That's essentially the same in protocol-03. The problem is
the following line in protocol-03 section 3.6.1:
| mechanism = name [ ":" domain-spec ] *( "/" *DIGIT )
Obviously wrong for the mechanisms ip4 or ip6, and IIRC nobody
reported this bug in the last call. Okay, you could say that
this "bug" already existed in draft-mengwong-spf-01.txt (3.2):
| mechanism = name [ ":" macro-string ] *[ '/' *DIGIT ]
"v=spf1 ip4:%{i} -all" is certainly something we don't need,
because "v=spf1 +all" does the same trick. And of course it
is not allowed to use macros with the mechanisms ip4 and ip6.
"v=spf1 exists:%{i} -all" is the same trick, and IMHO it also
isn't allowed, because "exists" requires a domain-spec, which
is a macro expanding into a FQDN, or a FQDN.
The protocol-03 ABNF doesn't reflect this directly, there's
only a verbose specification in 3.8. SH*T. That's a real bug.
We're lucky that none of the hardcore IETF nitpickers are on
this list... ;-)
The inclusion of a cidr length adds confusion. People are
not used to something that looks like domain.com/24. (is
that legal?
It's legal, and it makes sense (for SPF, not elsewhere). If
your outgoing MTA always has the same name, but its IP changes
very often (some sort of load balancing) within the same CIDR,
you can still say "v=spf1 a:my.mta.example/24 -all".
If it's really your own MTA "v=spf1 ip4:1.2.3.4/24 -all" would
be better for the receiver. But if it's something of your mail
provider, where you trust that the name is correct, but the IP
might change without prior notice, then a:name.example is more
reliable.
That is the way I read the specs, but I could be mistaken.
At least you wouldn't be alone with this interpretation... ;-)
Adding some "near misses" to the examples is a good idea. In
the case of the FQDN we need examples with IPs (invalid, no
FQDN), and with address literals (IPs in square brackets, also
invalid as per protocol-03 section 3.8).
Something with macro-string vs. domain-spec vs. FQDN vs. IP is
wrong in the protocol-03 syntax.
Bye, Frank