-----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