----- Original Message ----- From: "Hallam-Baker, Phillip" <[EMAIL PROTECTED]> To: "Stephen Farrell" <[EMAIL PROTECTED]>
> OK a new point, the SSP requirements need to be addressed > to different audiences: > > 1) Authors of software > 2) Operators of software. > > It seems to me that a lot of points here are only discussing > the second and thus we end up with more heat than light as > there is considerably greater variation in operational situations > than many expect. > > The specification is going to be written primarily for the authors > of the software rather than operators. Gee, I never thought of bringing this up as a requirement. You would think that this would be naturally expected. Smart move Phillip! Thanks! But without a doubt, I have often stated the debates are nearly always associated with the: Philosophical differences between Developers and Administrators. It happened in MARID, it happened in SPF, it happened with DKIM-BASE and it has happening now and it will always happen were there is a mix bag of professional disciplines. I guess that is why we have a consensus concept, but IMV, it is typically tilted in one direction from an administrator standpoint, atleast in the WGs I've participated in. <g> That isn't necessarily a problem. In this day of age where "All in One" and integrated packages, specially those that provide scripting designs or integration, admins have become to wear many hats, and vice a versa, developers are often users of their own creations and no doubt have to support their administrator customer needs. So there is a lot of wisdom here on both camps. >From my standpoint, for the problem related to the abuse of mail, the time has come where the SMTP vendor does more in the area - directly!! However, to keep with tradition, the SMTP vendor needs to only address strong compliancy issues with has been lacking. This is the sound approach that offers both technical (and legal) consistency. These options are programmed for administrators to use in thier local policy statements. The rest of the "indeterminate" mail, like now, is passed on to the administrator's other MFA (Mail Filtering Agent) tools. In the cased of SSP, this concept is one that is better understood by developers. When they see a DKIM-BASE and are asked to implement it, they have a better viewpoint of what are the implementation problems, specially those what can be address with a SSP concept. My personal concern, is that a standalone DKIM-BASE system has issues that have falling thru the crack. Some believe that a Trusted-Layer is all you need to fix the DKIM-BASE "cracks". That's probably true, but this is not defined and it fast materializing as a "batteries required" concept that will have many different market segments. SSP is a simple concept that deals with some rather simple policy concepts. I believe it should be part of the DKIM protocol like it was when it was first envisioned. Sometimes the best idea is the first one you think of. DKIM + SSP is a pretty sound concept for implementation into a mail design that I see will cater to my "operators of software" - without batteries. :-) Hector Santos, Santronics Software, Inc. http://www.santronics.com _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
