Frank -
Thank you for the careful, detailed review, edits and suggestions. I
have incorporated almost all of them. I felt you were owed some
explanation for the ones I didn't take:
Lines 372-374: question
that can be an address literal or entirely
malformed in a valid SMTP transaction. In these cases, check_host()
is defined in Section 4.3 to return a Fail result.
What's wrong with MAIL FROM:<postmaster(_at_)[1(_dot_)2(_dot_)3(_dot_)4]> ? It
has no sender
policy, but why is the result FAIL instead of NONE ? The snytax in
RfC 2821 apparently allows address literals in a MAIL FROM.
The treatment of "postmaster(_at_)[1(_dot_)2(_dot_)3(_dot_)4]" as Fail with reason "Malformed
Domain" is consistent with how "bob(_at_)bobs-machine" and "bob" would be
treated. While these might be legal MAIL FROM values for 2821, they
aren't things that can be evaluated by SPF.
---
Lines 555+564: delete
If both types of
records are returned for a domain, the SPF type MUST be used.
I prefer to think of this is line as the requirement, and the
algorithmic description just a consequence of implementing it.
---
Line 1086: please add a warning below your ASCII art, something like
| Note that it's a "PermError" to include a sender policy which does
| not exist.
This seems to be just a repeat of the very last line of the ASCII art
table. If seems very clear that a "None" result generates "PermError".
---
Line 1108: as discussed in other threads please add something like
| Note that a:192.0.2.1 or a:[192.0.2.1] would be invalid, use the
| IP4 resp. IP6 mechanisms to specify IPs directly.
Such things aren't supported by the grammar as it is. I'm going to
leave this one for the F.A.Q.s
---
Lines 1599-1600:
o = domain of <sender>
d = <domain>
| o = original domain, domain of <sender>
| d = <domain> of evaluated sender policy
The terms <sender> and <domain> are well defined in the document and
used consistently throughout. These macros are to expand to these
parameters of check_host(). I feel the added wording only adds doubt
that these terms might mean something different here than anywhere else
they are used.
---
Lines 1708-1709: <oops>
There is one deprecated macro letter: "h". It is expanded as the
string "deprecated".
That's a consequence of check_host() and its three arguments, the
HELO domain is unknown within check_host(). </oops>
Yes, I'm not so sure what to do about this. Macro letters came and
went over time. "h" is a big bear to put in as it is the only thing
that needs the HELO domain once processing is underway. It isn't
clear, also, how this macro can ever be useful, as there is just
nothing one can trust about the HELO domain.
---
Line 1925: maybe mention "backup MX" at the end of section 9.5, e.g.
| A border MTA performing SPF checks would typically "white list" all
| backup MX servers.
I started to add this, but then I felt like I was going to have to
explain all about backup MX servers. Basically, backup MX servers are
really your boarder MTAs anyway, so I left the text as is.
---
Line 2341: please remove the "/"
dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ]
Actually, this is right. If you want to have an ip6-cidr-length on a
"a" or "mx" mechanism, it requires two slashes:
a/26 - just an ip4 cidr length
a//80 - just an ip6 cidr length
a/26//80 - both
Indeed, the libspf2 test vectors bear this out.
If the slash were removed, then how would you know what
a/26
was? Is that an ip4 cidr length or an ip6 cidr length?
Perhaps we should have do this:
dual-cidr-length = [ ( ip4-cidr-length / "/" ) [ ip6-cidr-length ] ]
but alas, we didn't
- Mark