On Tue, May 31, 2005 at 10:02:51AM -0500, wayne wrote:
* The abstract now mentions both the MAIL FROM and HELO identities.
* The "scope" keyword-value pair has been renamed to "identity"
(Not much time to respond at the moment--trying to speed through a
long-ish response without it sounding to abrupt.)
I don't see the advantage in this change of wording:
1. Later versions of spf will end up with more fully fleshed-out
scopes.
2. We're basically doing scopes now with helo & mailfrom tests so
we may as well use terminology that will be compatible with future spf
versions,
3. We're really testing whether the connecting MTA has the
credentials to make a claim on behalf of a particular identity as
opposed to testing an identity itself,
4. And "scope" is easier to pronounce. :-)
Minor thing, but I don't see the logic in it.
* The "exp=" modifier no longer counts toward the DoS DNS lookup
limits.
Cool. I'm glad you made that change.
As to another change I've previously requested:
I previously thought that there was one recieved-spf header, and didn't
realize there was one-per-scope (or identity, using the new wording).
Finding out that there were multiple received-spf's, combined with the
new keyword, clears up most of my issues.
However, there is one remaining issue.
If reciever policy says that a failing mailfrom should be considered a
PASS because the verified HELO is trusted, how is that documented in
received-spf?
My understanding is that this sort of thing happens:
1. The mailfrom scope fails.
2. The MTA looks at local policy and pretends it passed.
3. Received-SPF merely mentions the failure, not the receiver or
recipient policies considering it as a pass.
4. Intelligent MUAs looking at headers think that the user was
sent an email that the user would consider a FAIL.
I would request a couple keywords where recipient conclusions can be
documented.
I haven't thought of a good set of words to use yet, hopefully folks
here can be more creative than I've been so far but I'm thinking of
usage that's something like:
policy_result/user(_at_)example(_dot_)com/policy1=neutral
policy_result/example.com/standardpolicy=neutral
policy_override_used=example.com/standardpolicy
In other words, the various possibilities could be documented, as well
as the one used. If no conclusions were documented, it would be assumed
that the spf-defined policy was used.
Then MUA's can show what the results would-have-been-like under other
more-restrictive policies. (Of course, the reverse isn't true if
failing incoming messages are rejected.)
Right now we're throwing away information about local policy--and in
fact the MUA won't have any way of knowing what local policy was.
If I'm reading mail that includes mail from my "whitelisted" forwarders,
I'd like my mua to be able to know what messages should be considered to
have passed spf tests according to local policy, even though they might
have resulted in an spf failure before local policy was applied.
Right now that information doesn't exist in the Received-SPF trace
header.
--
Mark Shewmaker
mark(_at_)primefactor(_dot_)com