On Sat, Aug 3, 2013 at 2:09 AM, Michael Deutschmann < mich...@talamasca.ocis.net> wrote:
> Your question about drafts has two possible implications. The first is > "I'm not going to pay any attention to Michael until he takes up RFC > lawyering." In which case I can't help you. > My problem is that absent a draft, you're lobbing a vague proposal over the wall and hoping the community will do all of the work for you. If your idea is a workable solution, I think it's reasonable for people to be convinced first that it's worth taking up the work. Popular forms of evidence are detailed specifications that can be analyzed and/or prototype implementations. As for your proposal, assuming I've understood it: The idea of requiring a first-party signature relative to the MAIL FROM, and using SPF to signal the requirement, runs into a couple of problems. The most obvious of these is that it presumes the author is covered by SPF, which is not universally true; the sending infrastructure may have chosen not to publish SPF due to false positives. That means this proposal is only useful to a subset of the community. That's a significant barrier. The community reached consensus some time ago that the absence of a valid first-party signature is not a reason in and of itself to distrust the message, because there are legitimate reasons DKIM can fail, and legitimate cases where a third party signs the message instead of the author domain. The DKIM RFC does state this fairly clearly. It's only the case where DKIM passes that you have actually learned something useful about the message. >From a protocol design perspective, using one protocol to signal an option in another almost orthogonal protocol is pretty weird. Coming up with standards-worthy signaling between the two, since SPF is almost always upstream of DKIM in terms of MTA processing, would be an interesting exercise. Otherwise you're presuming a single component is doing both tests, which is not commonly how it's done. All that said, I invite you to spend some time building an implementation and gathering statistics on its efficacy. Such data speak pretty loudly. There are plenty of APIs that would enable you to build something like this and try it in short order. If you decide to use libopendkim as part of the experiment, I pledge to support it; if it looks like your solution is useful, and the signalling question can be resolved, I'll add it to OpenDKIM. Another more general problem is that you appear to reject all of my mail because Gmail generates HTML mail, so hopefully you check the archives of this list once in a while. -MSK
_______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html