On Sat, Aug 3, 2013 at 2:09 AM, Michael Deutschmann <
michael(_at_)talamasca(_dot_)ocis(_dot_)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