Frank Ellermann wrote:
Jim Fenton wrote:
The SSP extension to key records would never be sufficient;
stand-alone SSP records would need to be published as well.
I'd like to suggest that we concentrate on the "basic" SSP
concept for now and keep optimizations such as this for
discussion later.
+1 It's kind of obvious that for *some* receivers and *some*
mails it might help to offer an "SSP-accelerator" in SPF, as
proposed by Scott (in 2006 IIRC). No issue for this WG. ;-)
Not sure of what specifically you are recollecting here, but I preached
back in August/2008 in SPF-DISCUSS the analysis for the SPF and DKIM
association:
http://article.gmane.org/gmane.mail.spam.spf.discuss/21503
and in thread follow ups, I provided an examples:
http://article.gmane.org/gmane.mail.spam.spf.discuss/21526
But all that was an independent consideration and didn't attempt to
change DKIM or SSP and/or attempt to create a dependency of mixed
SPF/DKIM technologies.
In my view SSP is 100% related to DKIM. SPF is not from standpoint
DKIM/SSP must be designed without any SPF dependency. So unless it is
your opinion the DKIM total solution includes SPF/SENDERID, I don't
understand why you keep injecting SPF here confusing the whole SSP/DKIM
model which already has its own contentious issues without SPF adding to it.
I'm not suggesting implementations will not do both, and in fact, I'm
sure most will, but they are really independent concepts and DKIM/SSP
must stand on its own and implementations must be ready to deal with it
independently.
My view Frank. No need to yell at me. :-)
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html