Issue 6: Doug's item about "7 days" in 5.2.
If verification is done in MUA, 7 days is not enough time for a key to
remain available. General agreement that there's a significant issue
here, but no good ideas how to resolve it. Given that, and the fact
that we were out of time, we will take the general question of
"verification in MUA" issues to the mailing list, with the note that
DKIM is intended to be primarily used in the MTA/MDA, but that it
should allow for MUA use in its design. We especially need to look at
the timeout and routine key rollover issues with that in mind.
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.
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=)
2) MUST perform the verification within the "transport window",
typically 7 days.
3) MUST store the results of the verification process if results of the
verification process
will be used for some later process
Mike
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html