On Apr 21, 2006, at 6:09 AM, Michael Thomas wrote:
IMO, the problem here saying that MUA's can praticipate in
verification is a large rathole. There many structural impediments
with them reliably verifying signatures. For one, many MDA's
torture messages in very DKIM unfriendly ways. Like sucking the
attachments into a database and regenerating the mime on output to
the MUA. For a pretty large class of MUA/MDA mating, it's my
understanding that trying to get this to work is pretty much
a fools errand.
While there are limitations to this approach, a subset of messages
survive these rigors. Transactional messages can still obtain
differential handling at the email viewing application within a
listed set of providers. It would be foolish to expect all message
types survive, or that all MDAs are DKIM friendly. The goals for
this approach are different. Benefits can be found without
deployment of DKIM related filtering at the providers. Filtering
also has limitations, as filtering tends to be reactive. DKIM at the
MDA has value. DKIM when the message is first being viewed has
value. Each offer different advantages and disadvantages.
On the DKIM side, however, if we define that MUA's can verify at
all, we need to exactly qualify what that MUA is to match the
general expectation we place on MTA's and MDA's: that they are
connected and that they are will verify the message within
reasonable transit time, and store the *results* of the
verification for later use if necessary (ie, it for display
purposes). If they won't or can't do those things, then they aren't
a DKIM-verification-capable MUA.
Thus a DKIM-verification-capable MxA:
1) MUST receive email in a form whose transformations fall within
the acceptable set of modifications as defined in -base-nn (eg,
canon, l=)
Of course.
2) MUST perform the verification within the "transport window",
typically 7 days.
The desired change to the base draft was to move the key retention
recommendation to a BCP. Indicate within the base draft the key
retention interval assures protection over the expected message
transit period. When the sender desires that this period allows
verification when first viewed, this interval may need to consider
typical variations seen over this transport. In the fullness of
time, global statistics will become available.
3) MUST store the results of the verification process if results of
the verification process will be used for some later process
A viewer may log these events, but should not predicate assurances on
less trustworthy result notations. Using untrustworthy results would
be foolish as well.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html