Would it make sense to break these up into separate threads? Anyway, here is my comments on some of these issues.
----- Original Message ----- From: "DKIM Chair" <[EMAIL PROTECTED]> To: <[email protected]> > * Issue: "r=" tag, specifying a "report-to" entity. Defer consideration > to SSP document, but then we considered whether to also have it in the > key record (or something reachable through the selector). Further > discussion to go to the mailing list. Personally, I like the idea of having a possible (by default) fixed notification common name (user part), such as one of following names: DKIM-ABUSE (My preference, since ABUSE is already required) DKIM-POSTMASTER DKIM-ADMIN DKIM-SYSOP etc. Dave Crocker's RFC 2142 can serve as a guide. Just a small note about operation consideration: The r= report address must be legitimate and acceptable. If a DKIM verifier attempts to send a report, it can learn very quickly if it is just a fraudulent address. So if not acceptable, it can become a source for putting more weight on a bad message. Some guidance should be provided for possible actions to take, i.e, stop sending future reports. > * Issue: transition plan for new crypto algorithms, and specifically, > transition from SHA-1 to SHA-256 hashes. Some discussion here, but > discussion ultimately deferred to the general issue of multiple > signatures. Consensus among the security folks is to let the verifier > decide which crypto is "best". I like the idea or the potential to offer high-value domains the ability to secure their operations by doing one or more of the following: 1) Assign domain owned user addresses for communications, 2) Joint venture, collaborate, outsource with a ESP that has the DKIM security we are looking for, and assign the user a special ESP domain controlled address. 3) During the user account sign-up we will automatically find out if the target domain offers the security we are looking for. In my view, the idea that high-value domains will place their faith on signing messages and then "cross their fingers" that it will be correctly be supported seems me to be a little unrealistic. This touches base with the following: > Jim Fenton introduced the signing policy/practices proposal and issues; > after the base document, we'll be attacking this in earnest. The name > is still in flux, with some thinking that "policy" is not the right > term, others thinking that "practices" isn't either. We were pointed to > some work called DDDS that's been introduced in the speermint working > group, which might help us with the work (not with the naming), so > we'll have a look at that. Practice? I would hope that everyone practices a safe DKIM Sender Signing Policy! :-) Labeling it as a "Sender Signing Practice" doesn't sound right. hmmmm, maybe it is obvious by now, but it should be highlighted that there seems to be two camps here in regards to SSP: - Those who think SSP is not necessary - Those who think SSP is vital to DKIM I think it is required. The specs has a natural presumption of a SSP Neutral policy (Missing SSP key defaults to NEUTRAL, o=~, policy). This is very important. Even if a domain doesn't define a SSP key, he is telling the world he is NEUTRAL. He doesn't care what happens to the message. What I seek operationally, is that everyone follows SSP verification/authorization whether one defines SSP record or not. The protection in DKIM comes when every piece of software is expected to practice SAFE SSP. So that if a DOMAIN says: "We don't send mail" "We never sign mail" "No 3rd party SHOULD ever sign our messages" etc, etc, it is vitally important that the domain policy, definition, "practice" or requirement, whatever we wish to call it, that we honor that security. I don't understand why we would want to ignore this fundamental domain security? So whatever we want to call it, to me, it a small moot point over what how we expect to use it. If it isn't require to be honored than what's the point? That said, I think ideas like DDDS and similar concepts is a step in the right direction. SSP will offer ways to resolve so many issues of "expectation" in a highly chaotic world of mail transactions. So whether its DDDS, SSP or what I call TMS (Transaction Management System), domains can learn more about who they are sending data to, as well as domains can learn about those they are receiving mail from. -- Hector Santos, Santronics Software, Inc. http://www.santronics.com _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
