On Mon, 1 Aug 2005, Hector Santos wrote:
[2] Arvel suggested another policy called WEAK which satisfies a
signature optional but not allowing 3rd party signers.
What is a reasoning behind the need for such option?
I see none since if signature is optional somebody who is trying to
pretend to be you need not resign the email - he can just go ahead
and use your existing email removing your signature from it (or compose
new email pretending to be you).
I will draw the outcome table in text mode. View it in fixed pitch mode.
Table 1.0 - DKIM Verification States illustrates all possible
outcomes for signature verifcation against SSP.
+------------------------------------------------------+
| Sender Signing Policy Result |
+-----------+----------------------------------------------+-------|
| result | WEAK | NEUTRAL | STRONG | EXCLU | NEVER | NONE |
| verify | OPT | OPT/3PS | REQ/3PS | REQ | | |
+-----------+--------+---------+---------+--------+--------+-------|
| NONE | accept | accept | reject | reject | reject | accept|
|-----------+--------+---------+---------+--------+--------+-------|
| PASS | accept | accept | accept | accept | reject | warn |
|-----------+--------+---------+---------+--------+--------+-------|
| PASS 3PS | reject | warn | accept | reject | reject | warn |
|-----------+--------+---------+---------+--------+--------+-------|
| FAIL | warn | warn | warn <.-+> warn | reject | warn |
|-----------+--------+---------+-------+-+--------+--------+-------|
| FAIL 3PS | reject | warn | warn <|-+> reject| reject | warn |
+--------------------------------------+---------------------------+
| ^
these all should be reject -+ |
|
warn from this column are unclear to me
The table is based on the current specification. It applies logic to
honor the OA SSP.
For example, an EXCLUSIVE policy can only be accepted when the non-3rd
party signature verification is successful (PASS). If the signature
verify fails, a possible warning may be shown, but the idea of how it is
displayed to the MUA is not the main point with the table. The goal is
the determination for the automation for acceptance and rejection which
of course can be local policy based.
You may display warning, but you should be clear if the warning is on
rejection or acceptance. My view is that warning is ok only if signature
verification fails but policy is not such as to reject. But if policy
is to reject, warning is not sufficient.
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net