John L wrote:
I mostly want to be sure we lose the language about not showing
the effects of non-author signatures, which is just wrong.
Note "Assessments" box and replacement of Note to use your text. I think we are
done:
<artwork name="DKIM Service Architecture"><![CDATA[
|
|- RFC2822 Message
V
+--------+ +--------------------------------+
| Private| | ORIGINATING OR RELAYING ADMD |
| Key +..>| Sign Message |
| Store | +---------------+----------------+
+--------+ |
(paired) |
+--------+ | +-----------+
| Public | | | Remote |
| Key | [Internet] | Sender |
| Store | | | Practices |
+----+---+ | +-----+-----+
. V .
. +--------------------------------+ .
. | RELAYING OR DELIVERING ADMD | .
. | Message Signed? | .
. +-----+-----------------+--------+ .
. |yes |no .
. V | .
. +-------------+ | .
+......>| Verify +-----+ | .
| Signature | | | .
+------+------+ | | .
pass| fail| | .
V | | .
+-------------+ | | .
| | | | .
+......>| Assessments | | | .
. | | V V .
. +------+------+ +-------+ .
. | / Check \<...........+
. +------->/ Signing \
. | / Practices \<.........+
. | +-------+-------+ .
. | | .
. | V .
+----+--------+ | +-----------+ +------+-----+
|Reputation/ | | | Message | | Local Info |
|Accreditation| +------->| Filtering | | on Sender |
|Info | | Engine | | Practices |
+-------------+ +-----------+ +------------+]]>
</artwork>
</figure>
<t>As shown in <xref target="DKIMSvc" />, basic message processing is
divided between a signing Administrative Management Domain (ADMD)
and a validating ADMD. At its simplest, this is between the
Originating ADMD and the delivering ADMD, but can involve other
ADMDs in the handling path. <list style="hanging">
<t hangText="Signing: "> Signing is performed by an authorized
module within the signing ADMD and uses private information
from the Key Store, as discussed below. Within the
originating
ADMD, this might be performed by the MUA, MSA or an MTA.</t>
<t hangText="Validating: "> Validating is performed by an
authorized module within the validating ADMD. Within a
delivering ADMD, validating might be performed by an MTA, MDA
or MUA. The module verifies the signature or determines
whether a signature was required. Verifying the signature
uses
public information from the Key Store. If the signature
passes, reputation information is used to asses the signer
and
that information is passed to the message filtering system.
If
the signature fails or there is no signature, information
about the related signing practices is retrieved remotely
and/or locally, and that information is passed to the message
filtering system. </t>
<t hangText="Note: "> If message has more than one valid
signature, the order in which the signers are assessed and
the
interactions among the assessments are not defined in this
document. </t>
</list>
</t>
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html