>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. >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. >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. In the typical case where the user gets all his mail from a single known-friendly POP server, it's easy enough to pick the delivery date out of the top Received: header to see when it was delivered. Even if it's been a while, the incremental security risk of checking a two week old signature versus a one week old signature is pretty puny compared to the presumably large benefit of verifying that a message was signed. I still don't understand the point of trying to prevent people who don't read their mail every day from using DKIM. >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. So anyway, here's two concrete suggestions: a) The spec should say that DKIM is intended for securing messages in transit rather than messages in an archive, and leave it at that. In particular, I realize that a week is a practical limit for message transit, but I haven't seen any cryptographic justification to limit signature lifetimes to a week rather than an hour or a month. 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. R's, John _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
