ietf-dkim
[Top] [All Lists]

[ietf-dkim] SSP Related issues [was Re:dkim.org (mipassoc.org/dkim) web page updated]

2005-11-12 20:35:08

----- Original Message -----
From: "Douglas Otis" <dotis(_at_)mail-abuse(_dot_)org>
To: "Hector Santos" <hsantos(_at_)santronics(_dot_)com>

On Fri, 2005-11-11 at 04:12 -0500, Hector Santos wrote:

This might make it easier using this format to provide ACCEPT,
REJECT, WARN final results:

2821 =  PASS Yes/No
2822 =  PASS Yes/No

You change the "rules!" - again!  Doug, I'll give you thing.  You are
consistent. :-)   The lack of an answer proves my entire point of the 2821
vs. 2822 exercise and to make a long story short, DKIM/SSP needs to stand on
its own. It can be integrated with other ideas, but it can't be dependent on
it because once it is, the issues become too wide, too complex and costly.
We are back to square one.  As it is, it will difficult to keep 2821 related
concepts out of the mix, but that all depends on which school of thought you
are from and without a doubt, more related to implementation suggestions.

I will say this and leave it at that:

SMTP based ideas are here to day. Ideas such as SPF and CBV are not going to
go away or be replaced with any PAYLOAD solution.  We are interested in DKIM
to provide a non-existing PAYLOAD methodology as part of a total mail
security system.  There will be those who use DKIM only and there will be
those who use SMTP level methodologies only, and there will be those who
will want to use both.  I can't enforce any of this on customers. They will
choose what is best for them.  My job is only to make sure that they are
independent of each other, but work together and in many ways, consistent
with each other and more importantly, backward compatible with the 20+ years
of SMTP standard and BCP operations.

Here are my 2821 vs 2822 table filled in:

  +------------------------------------------+
  |      |              SMTP x821            |
  |      |-----------------------------------+
  | x822 | NONE   | PASS   | FAIL   | PUNT   |
  |------+--------+--------+--------+--------|
  | NONE | ACCEPT | ACCEPT | REJECT | warn?  |
  |------+--------+--------+--------+--------|
  | PASS | accept | ACCEPT | reject | warn?  |
  |------+--------+--------+--------+--------|
  | FAIL | reject | warn?  | REJECT | reject?|
  |------+--------+--------+--------+--------|
  | PUNT | warn?  | warn?  | reject | warn?  |
  +------------------------------------------+

In my view, uppercase results are HARD decisions. Results with ? are
subjective.  All results depends on your point of view.

Now, I was hoping to finally show how it compares with DKIM/SSP:

                     Table 2.0
       Comparison of SMTP verification results
               with DKIM SSP Results
  ================================================
  |          |       SMTP 2821 Verification      |
  | DKIM     |-----------------------------------+
  | SSP      | NONE   | PASS   | FAIL   | PUNT   |
  |==============================================|
  | NONE     | ACCEPT | ACCEPT | REJECT |        |
  |----------+--------+--------+--------+--------|
  | PASS-OA  |        | ACCEPT |        |        |
  |----------+--------+--------+--------+--------|
  | PASS-3PS |        | ACCEPT |        |        |
  |----------+--------+--------+--------+--------|
  | FAIL-OA  |        |        | REJECT |        |
  |----------+--------+--------+--------+--------|
  | FAIL-3PS |        |        | REJECT |        |
  ================================================

The above are hard decisions, the "partials" as Barry may put it, are
removed.  But once you consider implementation details, well, it all
depends on your point of view. No easy answer.

One quick POV example:

   For the DKIM only system, the 2821.NONE column will
   follow the result of DKIM.

My personal POV implementation will basically use the above HARD decisions
as the only real high trust decisions.  Of course, the NONE/NONE state is
simply the legacy and backward compatible decision, I will also use the
2821.FAIL column as a trump for DKIM/SSP (all rejects) since I believe two
concepts must be consistent in order to be a valid good-actor transaction.
Everything else is just passed (accepted) for the local sysop to use as he
sees fits.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com



_______________________________________________
ietf-dkim mailing list
http://dkim.org

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