Julian,
I don't disagree with your point, but I was thinking why its not possible to
take what we have today with SPF today and what's coming tomorrow with DKIM
to help develop some SPF/DKIM integration guidelines?
How can DKIM help make SPF stronger, today?
Example:
What are the possible results for SPF?
NONE
NEUTRAL
PASS
FAIL
SOFTFAIL
TEMPERROR
PERMERROR
And the DKIM BASE possible results?
1PPASS - 1st Part valid signature
1PFAIL - 1st party invalid signature
3PPASS - 3rd Part valid signature
3PFAIL - 3rd party invalid signature
When you combine the two what are the possible states and interpretation?
Well, in theory you have 6 x 4 or 24 possible states. When you complete
this 6x4 table grid, there will be a very strong results included with
indeterminate.
Some example of the pretty strong trusted results:
SPF-PASS + DKIM-1PPASS = PASS
SPF-FAIL + DKIM-1PFAIL = FAIL
What about the others 22?
How can we make the SPF-NEUTRAL a pass or a fail?
SPF-NEUTRAL + DKIM-1PPASS = PASS?
SPF-NEUTRAL + DKIM-1PFAIL = FAIL?
SPF-NEUTRAL + DKIM-3PPASS = PASS MAYBE??
SPF-NEUTRAL + DKIM-3PFAIL = FAIL MAYBE??
Or a SOFTFAIL a real FAIL?
SPF-SOFTFAIL + DKIM-1PFAIL = FAIL?
SPF-SOFTFAIL + DKIM-3PFAIL = FAIL? MAYBE?
etc, etc.
This is something that should be talked about.
If someone wants to create the 6 x 4 table grid of SPF vs. DKIM results to
kick start these considerations, please do. :-) Put in your initial
thoughts on what the results for each cell should be and then we can debate
and fine tune it.
If we to simplify it, we can just consider PASS/FAIL DKIM results and not
get into complex 1st party vs. 3rd party issues for now. But IMHO, they do
matter in the "trusted" weights of the results.
Comments?
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
----- Original Message -----
From: "Julian Mehnle" <julian(_at_)mehnle(_dot_)net>
Newsgroups: spf.-.sender.policy.framework.discussion
To: <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>
Sent: Saturday, August 12, 2006 4:14 PM
Subject: [spf-discuss] Re: DKIM-SSP integration SPF
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hector Santos wrote:
If it has not already been done, I think it is fast approaching the time
the SPF community develop a clear picture on how it will accept and live
in a future DKIM-SSP world.
I agree.
SPF includes administrators, developers and vendors and together, we
should work out the logic of how SPF can work with DKIM:
- how it can make DKIM-SSP better,
- how DKIM-SPP can make SPF better.
This subject of extending SPF to cover other authentication methods has
been touched on spf-discuss in the past. In particular, I'd like to point
to the following threads:
* "PGP"
http://thread.gmane.org/gmane.mail.spam.spf.discuss/20382/focus=20718
* "SPFv2.1: whether, why, and what?"
http://thread.gmane.org/gmane.mail.spam.spf.discuss/20730/
I don't think the question should read "How can SPF make DKIM-SSP better?"
or "How can SPF benefit from DKIM-SSP?", though. I think the important
question is:
What kind of sender policy framework does the e-mail system need?
(Although, perhaps, we can answer all of those questions with a common
solution.)
I think e-mail senders should be able to express their sending policies as
accurately as possible, within certain reasonable constraints, such as
keeping complexity reasonably low (i.e. not supporting every conceivable
policy on earth, just the most used ones).
I think a sender policy framework should serve for receivers to determine
the legitimacy of messages. Meaning that if a message complies with a
domain's asserted policy, it can be considered sanctioned by the domain
owner (not in a legal sense, of course! *sigh*). It should be within a
domain's power to define what constitutes legitimacy. If a domain defines
legitimacy via authorization of IP addresses, then they say "a", "ip4"/
"ip6", or "mx". If a domain defines legitimacy via DKIM signing, then
they
should be able to say "dkim:...". Methods can be combined as desired.
"include" works as it does now.
That's how _I_ view the connection between SPF and DKIM. In that, I still
concur with Meng's (or whose?) original concept.
If this has been discussed, chatted, or debated, we should pound it out
and document it into a official SPF-DKIM-SSP Integration IETF I-D
document.
Unless anyone else wants to do it, I volunteer to write the I-D document
once the interface requirements are worked out, which includes working
with the final deposition of the DKIM-SSP design.
I figure this would be the part (a section) of a future SPFv2.5 specifi-
cation that covers a hypothetical new "dkim" mechanism. I see no problems
with working on that isolated from other eventual new features of a new
SPF revision. However we might have to review and extend the current set
of "assertion primitives" (result codes), which is essentially limited
to "Pass", "Fail", "SoftFail", and "Neutral" at the moment.
(I even know that some consider it possible to resolve the issue using
merely a new modifier within v=spf1, but I don't subscribe to that. New
semantics need to be implemented and deployed in any case, so why not go
all the way and seize all the other benefits a new SPF revision could
bring?)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
iD8DBQFE3jbAwL7PKlBZWjsRAsZWAJ9gTbkmapfIuZVbsBJyXyObcEx/wACfVWEf
humE4Q+4qZcZersti/FFE9s=
=Lk1Q
-----END PGP SIGNATURE-----
-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com