Some initial thoughts on first reading of core-00:
Section 3. The "error" result from SPF (which indicates a SERVFAIL
during a DNS lookup) isn't included in MARID. I'm curious as to the
reason for this decision -- returning a 4xx SMTP code if the MAIL FROM
doesn't resolve is already common practice as an anti-spam measure; it
seams reasonable to do likewise for the PRD.
And, as has been discussed on the SPF list in the past, saying that an
MTA SHOULD return a 4xx response if it gets a DNS failure removes the
incentive for an attacker to DoS a nameserver in the hope that a
forged message may get more favourable treatment.
I suppose an argument against is that in the presence of includes and
redirects, in introduces too many failure points...
Section 4: PRA algorithm. I'm a little nervous about using headers
that aren't specified by the RFCs, though I can see the pragmatic
benefit. If you go down this route, there should probably be a
companion RFC that formally defines the semantics of these headers.
See also my separate post on the PRA algorithm.
Section 5.1.5: "exists in the DNS" is problematic, although I'm not a fan of
SPF's semantics, either, which are "has an A record".
A domain can exist, but have no resource records (if it has children).
If we go for "exists in the DNS" then there should probably be an
implementation note suggesting how to check for this (ie perform an
ANY query, and see if you get NXDOMAIN) -- and pointing out that this
isn't equivalent to checking whether any RRs are returned.
Actually, I think I'd prefer "has any resource records associated with
it" to "exists in the DNS" since this is more flexible.
Consider the names:
a.b.example.com
b.example.com
If the first exists in the DNS, then the second by definition exists
in the DNS too. If you make the criterion whether the name has any
RRs then you can choose the result independently for both names. It's
probably also more intuitive to people who aren't intimately familliar
with the DNS protocol.
5.1.7 Just an observasion that the mx element has different semantics
from the mx method in SPF. The mx method in SPF only looks up MX
records of the current domain, never A/AAAA records. I have no strong
preference one way or another on this issue, and since the new policy
is more liberal than the old, it's unlikely to cause problems for
people with existing SPF records.
5.2.1 Tony Finch recently observer on the SPF list that the limit of 9
for the number of componets to use in a macro makes the mechanism
rather less than useful when dealing with IPv6 addresses, which
consist of 32 components. I believe Meng had upped this limit to 128
in his working SPF draft. I don't think it necessarily needs to be
that high, but I think it should be at least 32.
7.1 DBS attacks. Should probably mention the possibility of a DoS
attack on a nameserver to force "unknown" (unless the behaviour is
reverted to the SPF behaviour).
9.2 Most of today's forwarders already add an appropriate header...
Perhaps "many" rather than "most". Sendmail certainly doesn't.
9.6 When a received message contains multiple headers that might be used
for the purported responsible address determination, an MUA should
consider displaying all of them.
I'm not sure what this means. The algorithm in section 4 always
selects a single header.
-roy