This might make it easier using this format to provide ACCEPT, REJECT, WARN
final results:
2821.NONE + 2822.NONE =
2821.NONE + 2822.PASS =
2821.NONE + 2822.FAIL =
2821.NONE + 2822.PUNT =
2821.PASS + 2822.NONE =
2821.PASS + 2822.PASS =
2821.PASS + 2822.FAIL =
2821.PASS + 2822.PUNT =
2821.FAIL + 2822.NONE =
2821.FAIL + 2822.PASS =
2821.FAIL + 2822.FAIL =
2821.FAIL + 2822.PUNT =
2821.PUNT + 2822.NONE =
2821.PUNT + 2822.PASS =
2821.PUNT + 2822.FAIL =
2821.PUNT + 2822.PUNT =
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
----- Original Message -----
From: "Hector Santos" <hsantos(_at_)santronics(_dot_)com>
To: "Douglas Otis" <dotis(_at_)mail-abuse(_dot_)org>; "Scott Kitterman"
<ietf-dkim(_at_)kitterman(_dot_)com>
Cc: <ietf-dkim(_at_)mipassoc(_dot_)org>
Sent: Friday, November 11, 2005 3:49 AM
Subject: Re: [ietf-dkim] Re: dkim.org (mipassoc.org/dkim) web page updated
----- Original Message -----
From: "Douglas Otis" <dotis(_at_)mail-abuse(_dot_)org>
To: "Scott Kitterman" <ietf-dkim(_at_)kitterman(_dot_)com>
Getting SSP right would be of much greater value to me that
going off on the tangent that you propose.
You are advocating changing email practices. Allowing current practices
is not a tangent.
Doug, lets have some fun here. Maybe this will help the focus, maybe not.
Anyway is welcome to join and play and get your views on this.
Given the following email security protocol independent model:
2821.METHOD + 2822.METHOD = FINAL_RESULT
Where 2821.METHOD is an one or more security algorithm at the SMTP Level
which produces one of the following results:
NONE
PASS
FAIL
PUNT (indeterminate, no decision, give up, "neutral-like")
Where 2822.METHOD is an one or more PAYLOAD security algorithm at the 2822
Level with one the following results:
NONE
PASS
FAIL
PUNT (indeterminate, no decision, give up, "neutral-like")
and FINAL_RESULT is combined result of 2821.METHOD and 2822.METHOD.
There are 4x4 or 16 possible final results which can be shown using this
table:
FINAL_RESULT
+------------------------------------------+
| | SMTP 2821 |
| |-----------------------------------+
| 2822 | NONE | PASS | FAIL | PUNT |
|------+--------+--------+--------+--------|
| NONE | | | | |
|------+--------+--------+--------+--------|
| PASS | | | | |
|------+--------+--------+--------+--------|
| FAIL | | | | |
|------+--------+--------+--------+--------|
| PUNT | | | | |
+------------------------------------------+
Using the following terms:
ACCEPT
REJECT
WARN
Please fell out the table above.
This will illustrative the fundamental and philosophical differences many
have here depending on which school you are from. There is no wrong or
right answer. Just how people feel things "should work."
Notes:
View NONE as a condition where there is no information available for the
requested entity, i.e., NXDOMAIN.
View PASS as the condition that passes the METHOD test with 100%
certainty.
View FAIL as the condition that fails the METHOD test with 100% certainty.
You could PUNT as a condition that could be like a PASS or FAIL but the
method could not do so with 100% certainty. Like a SPF-NEUTRAL.
Also, if you wish, you can weight on the final result like ACCEPT1,
ACCEPT2,
WARN3 or for results you are not sure which way it could go, use a
question
mark, like WARN?, PASS?, etc. If you don't have a question mark, I will
assume you consider the result a "hard decision."
If you like, please provide (short) reasoning for a result you think needs
clarification.
Be looking forward to your "thinking." <g>
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
ietf-dkim mailing list
http://dkim.org
_______________________________________________
ietf-dkim mailing list
http://dkim.org