Mark Lentczner wrote:
I have completed a draft that describes SPF v1 for submission
Good stuff, thanks. See below for some observations sorted by
line numbers in the paginated text version.
---
Line 184: s/my/may/
This document defines a protocol by which hosts my be authorized by
---
Lines 310-316: delete
However, software could perform these
checks at a different time, and if so, may extract the reverse-path
from the "Return-path" header as described in [RFC2821]. However, it
must be noted that while required, not all software complies with
inserting such headers. Furthermore, in these cases, if the
reverse-path is null, there may not be a reliable way to determine
the corresponding EHLO or HELO domain from the "Received:" headers.
Another problem is to determine the IP in these cases. And of course
you must be online to get sender policies. All in all better don't
mention this approach and its various problems here, you already have
better descriptions in section 9.5 and in lines 344-347:
Typically,
such checks are done by a receiving MTA, but can be performed
elsewhere in the mail processing chain so long as the required
information is available.
---
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.
---
Line 385: s/As decribed above, it/It/
approach: 1) As described above, it may not be possible to
Only if you deleted lines 310-316, as described above... ;-)
---
Lines 555+564: delete
If both types of
records are returned for a domain, the SPF type MUST be used.
They MUST be identical. It's not the problem of the receiver if they
are not, the receiver can use whatever it gets. You don't need this
additional "MUST", lines 790-791 (record selection) are good enough:
1. If any records of type SPF are in the set, then all records of
type TXT are discarded.
---
Line 748: s/the check_host/then check_host/
If the <domain> is not an FQDN, the check_host() immediately returns
---
Lines 811-813: unclear definition of "well formed" (?)
Implementations MAY choose to parse the entire record first and
return "PermError" if the record is not well formed. See Section
7.1.
Please add "about unknown mechanisms (defined in Appendix A)". It's
not exactly obvious why this "MAY PermError" is compatible with the
"MUST evaluate" in 7.1. I needed some time to get the idea than an
unknown-mechanism like "foo" (in 7.1) is still well formed (in 4.6).
---
Line 829: replace this by the ABNF in lines 2315-2317
mechanism = name [ ":" domain-spec ] *( "/" *DIGIT )
The idea of the "collected ABNF" is to collect the ABNF. And in the
case of IP4 or IP6 there's no optional "domain-spec". PTR has no
CIDR. The CIDR is optional, it has not the form *( "/" *DIGIT ).
---
Line 934: missing "several"
For mechanisms, the <domain-spec> is optional.
For "exists" and "include" it's required, so that should be "several
mechanisms". IP4 and IP6 don't have a <domain-spec> at all.
---
Lines 979-982: delete
Mechanisms either match, do not match, or throw an exception. If
they match, their prefix value is returned. If they do not match,
processing continues. If they throw an exception, the exception
value is returned.
You already had this in 4.6.2 (lines 854-879) with all the details.
---
Lines 997-1002: unclear
While
fetching that information and DNS server returns an error (RCODE
other than 0 or 3) or the query times out, the mechanism throws the
exception "TempError". Should the server return "domain does not
exist" (RCODE 3), then evaluation of the mechanism continues with an
empty set of records.
How about:
| If the DNS server returns an error (RCODE other than 0 or 3) or the
| query times out, the mechanism throws the exception "TempError". If
| the server returns "domain does not exist" (RCODE 3), then the
| evaluation
...does something, but what ? If I have "v=spf1 a:domain.test -all",
which "set of records" is then "empty" ? Why not simply say that the
mechanism doesn't match ? Even an "a:domain.test/0" doesn't match.
---
Lines 1032-1033: s/as /as in the /
The <ip> and <sender> arguments remain the same as current evaluation
of check_host().
Or just say "... remain always the same." If implementors want to use
global variables they'll take this hint.
---
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.
---
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.
---
Lines 1367-1368: delete "either from a cache or via a query to DNS".
The DNS TXT record for the <target-name> is fetched
either from a cache or via a query to DNS.
SPF isn't the place to explain the mysteries of DNS caches... ;-)
---
Lines 1480-1482: <joke>
implementation that did not recognize the "foo" mechanism would
return "PermError". An implementation that did recognize the "foo"
mechanism would be able to perform an extended evaluation.
In other words the sender shouldn't send mail to receivers which have
not yet implemented the "foo" mechanism. </joke>
---
Line 1521-1522: s/try keep/try to keep/
Domains publishing records SHOULD try keep the number of include
directives and chained redirect modifiers to a minimum.
Please try to keep the upper case for all mechanisms and modifiers,
here s/include/Include/ and s/redirect/Redirect/.
---
Line 1536: s/the A for records/the A records/
MX records for "example.com", and then the A for records for the
---
Lines 1580+2346: s,v-char-ms,v-char-dm / "/",
macro-string = *( macro-char / v-char-ms )
Lines 1587-1588 and 2363-2364: delete v-char-ms
v-char-ms = %x21-24 / %x26-7E
; visible characters except "%"
---
Lines 1599-1600:
o = domain of <sender>
d = <domain>
| o = original domain, domain of <sender>
| d = <domain> of evaluated sender policy
Already reported by Nate in MARID for protocol-03.
---
Line 1613: replace
The uppercase versions of all these macros are URL-encoded.
Please replace this by lines 1717-1718 with the explanation:
Uppercased macros expand exactly as their lower case equivalents, and
are then URL escaped. URL escaping is described in [RFC2396].
---
Line 1633-1635: delete
Note that the two different macro contexts, domain-spec, and
macro-string allow slightly different sets of legal visible
characters, v-char-dm and v-char-ms respectively.
That's obvious: No slash _in_ domain-spec because it's used to start
a dual-cidr-length _after_ the domain-spec. Get rid of v-char-ms.
---
Line 1672: s/during a/during/
Note that these values remain the same during a
---
Line 1689: s/to dot/to a dot/
For IPv6 addresses, the "i" macro expands to dot-format address; it
---
Lines 1703-1705: s/MAY/may/
The domain name
MAY be different than the name found in the MX record that the client
MTA used to locate the receiving MTA.
That's not an option, that's a fact... ;-)
---
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>
---
Line 1895: s/sender of receiver/sender and receiver/
relays between sender of receiver of an e-mail message. However, the
use of open MTA relays on the Internet has long been noted as a
security problem. Most sites do not run open relays and many refuse
e-mail from known open relays.
Please delete "However" etc., SPF has nothing to do with open relays.
If I'd plan to use an open relay I could add it to my sender policy.
---
Line 1915: s/this is/these are/
this is just the border MTAs as internal MTAs simply forward mail to
---
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.
---
Lines 2150-2161: delete (already mentioned in line 2147)
The folks in the MARID working group and on the MXCOMP mailing
list.
Maybe add "All early adoptors of SPF." That would cover my ISP. ;-)
---
Line 2333: Missing URL (?)
EMail: mengwong+spf(_at_)pobox(_dot_)com
| URI: http://spf.pobox.com/
You removed the mailing list address in draft-mengwong-spf-01.txt, but
with this obvious URL it's easy to find many related links.
---
Line 2341: please remove the "/"
dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ]
---
I've not checked appendix B, are there any completely new examples ?
And I've ignored the <domain-spec> problem reported by Mark Holm in
the "ebay" thread. Maybe it's all in line 829, and then you could
replace...
mechanism = name [ ":" domain-spec ] *( "/" *DIGIT )
...by the ABNF for unknown-mechanism (without unknown- in line 829):
mechanism = name [ ":" macro-string ]
Bye, Frank