ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] SSP requirements

2006-08-08 15:56:59

----- Original Message -----
From: "Hallam-Baker, Phillip" <pbaker(_at_)verisign(_dot_)com>
To: "Stephen Farrell" <stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie>


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

<Prev in Thread] Current Thread [Next in Thread>