Re: [ietf-dkim] DKIM verification in MUAs

John Levine wrote:

IMO, the problem here saying that MUA's can participate in
verification is a large rathole.
    

Maybe, but it's also a rather important usage model and we dismiss it
at our peril.  Partly that's because it'll slow down adoption, partly
it's because people will do it anyway regardless of what we say.
  

The model that I think is far more likely is a signing MUA. At least that's the
model _I_ want for myself. Trusting DKIM verification to MUA's given
the vagueries of transit and unhelpful message stores seems... well... not
a great idea to me, but if it works for some people great.

1) MUST receive email in a form whose transformations fall within the 
acceptable set of modifications as defined in -base-nn (eg, canon, l=)
    

Right.  Fortunately, anything that picks up mail with POP or IMAP
should be OK.  And we don't have to spec that -- if the delivery
process smashes the mail, the signature will break regardless of where
in the chain the smashage happens.
  

Right, this entire subject seems like it ought to be part of the BCP. The -base
document should probably mention as tersely as possible that verification in
MUA's may work in certain relatively narrow circumstances, and that widening
the scope is a non-goal.

2) MUST perform the verification within the "transport window", 
typically 7 days.
    

Sorry, no, we're back to a previous argument.  If someone goes away
for two weeks, and comes back and picks up his mail, his MUA is going
to check the signatures regardless of how many MUST NOTs you try to
put in the spec.  
  

So what? Nobody's saying that they can't try. Nobody's saying that it will be
guaranteed to work either. Nor will we be saying that.

I still don't understand the point of trying to prevent people who
don't read their mail every day from using DKIM.
  

Because the signatures and selectors are not intended to make long term
assertions. If I remove my selector from DNS before you get around to verifying
your mail, tough. That's not the problem we're trying to solve for. Have your
MDA or something else do it for you if you want reliability.

3) MUST store the results of the verification process if results of the 
verification process will be used for some later process
    

Honestly, that's none of our business.  Maybe they prefer to cache the
key and rerun the verification later, or something else we haven't
thought about.
  

The only thing I'm trying to reinterate here is signatures/selectors are here
today, gone tomorrow; store it or lose it.

b) It'd be a good idea to discourage people from reusing a selector
with a different key.  If you change the key, change the selector, and
don't just alternate two selectors every month with a new key every time.
  

I believe that's already in the normative language of the draft.

       Mike

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html