Re: [ietf-dkim] DKIM verification in MUAs

[Michael Thomas]

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