|
Re: [ietf-dkim] DKIM verification actors
2006-04-21 09:02:26
I think you've got this turned completely inside out. I'm not trying to
say what an
MUA MUST do. I'm saying that we should define the conditions under which
DKIM
signature verification is supposed to work. This may work for some
MUA's, and it
may not. If an MUA can meet those conditions and find DKIM verification
useful,
by all means. But please don't come back and say that DKIM is broken
because it
requires temporal, and other conditions that DKIM was not designed to
support.
more:
Paul Hoffman wrote:
At 6:09 AM -0700 4/21/06, Michael Thomas wrote:
IMO, the problem here saying that MUA's can praticipate in
verification is
a large rathole.
"can participate" and "can participate as well as MTAs" are very
different things.
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.
If this is true, then wouldn't most MUAs fail to work with OpenPGP and
S/MIME messages? Or are you saying that the MDAs munge the headers
particularly hard? We know that some MUAs are useless with OpenPGP and
S/MIME, but that most work fine.
No, as I understand the problem these message stores save the attachments in
a database and regenerate the message in the mapi/pop/imap stage to the MUA.
The relationship between the input and output may be completely dissimilar
which causes DKIM signatures to fail. PGP and SMIME work because they
are attachments and assumedly the message store doesn't change them.
AFAIK, both Exchange and Lotus Notes do this. There may be others.
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.
Fully disagree. MUAs can do their best to validate well, and we can
suggest how to do that, but we cannot mandate it.
I'm not mandating anything. Just describing the necessary pre-conditions
for it
to work in an MUA.
1) MUST receive email in a form whose transformations fall within the
acceptable set of
modifications as defined in -base-nn (eg, canon, l=)
Thus a DKIM-verification-capable MxA:
How could we measure that, much less enforce it? Some MxAs will work
fine with one set of messages and break with a different set.
No enforcement. "if you want this to work, these are the preconditions
you must
insure".
2) MUST perform the verification within the "transport window",
typically 7 days.
How could we enforce that with an MUA? Obviously, it would try to
verify immediately on receipt, but an MUA cannot be forced to download
mail when the computer is off. For that matter, an MTA cannot do it
either. You are defining a system, not an MxA.
No enforcement. "if you want this to work, these are the preconditions
you must
insure".
3) MUST store the results of the verification process if results of
the verification process
will be used for some later process
How would the MxA know that the results would be used by a later
process? Are we going to create a protocol for the later process to
tell the upstream MxAs that they need the verification results? (The
latter question is meant to be humorous....)
We've already been talking about the Auth-Results, but that's a specific
instantiation of
that data. There are many more possibilities, some that don't require
any standards work
at all, and some that might. For -base, we can be value about this and
just couch it in
terms of "storing it locally" or somesuch and defer any of this talk to
a later date.
Mike
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
|
|