Scott Kitterman wrote:
OTOH, it seems to me that it's been said Ad Nauseum. Where
feasible I agree it's better, but there are operational frictions
that will impede this approach in some cases.
Michael Thomas wrote:
What I believe that we've discovered is that this isn't nearly
simple as some people hoped. Doing as little up front as possible
so that you can get operational experience is almost certainly
better than guessing -- especially when the guessing wrong is
a likely outcome. In this particular case, I dooubt there will be
harm because receivers will always have an incentive to make
better decisions (and hence the desire to upgrade).
By the same token, lets not exclude the possible (including the belated)
recognition of some problems and the receiver decision to either a) punt on
DKIM, or b) use the new failure discoveries as a way to further filter bad
mail much to the chagrins of those who want all DKIM mail to reach some
trusted-layer or the final user.
In my view, the only guessing here is who some are believing that DKIM-BASE
will be accepted as is and that receivers will past the buck to trusted
layers. That would be a highly risky erroneous presumption to make for a
wide adoption strategy. It may work in the vertical market but not in the
horizontal market, in fact, there is a high probability that the horizontal
market may suffer some consequences when the high-value smaller vertical
market begin to get exploited, by name only, and the attacks are focused
much larger segment of the market.
But I agree, receivers will be quick to recognize the problems promoted by
the uncontrolled usage of DKIM-BASE protocol and will adapt accordingly.
Having said that, the only thing I seek, I don't care how you want to do it,
is to offer controls of who is allowed to sign mail on the behalf of the
2822.From: domain and I don't want a "batteries required" concept of asking
some independent organization for this basic protocol consistency
information.
That will happen anyway but only after all the i's are dotted and t's are
crossed. No one has disputed reputation or accreditation ideas. They are
also part of total picture solution. But for DKIM-BASE, we have some
fundamental protocol inconsistencies issues that can be easily resolved with
signature authorization policy ideas such as SSP.
Finally, I think most of it is already covered, as witness with the SendMail
Milter public open source code (dkim-milter-0.5.1) which currently supports:
Signature Optional (o=~ DKIM_POLICY_SIGNSOME)
Signature Expected (o=- DKIM_POLICY_REQUIRED)
Signature Not Expected (o=. DKIM_POLICY_NEVER)
However, the 3rd party restrictive policy DKIM_POLICY_AUTHORITY (o=!) as
defined in SSP-01 and a header bit declared, is not supported in the milter.
There is no action for it. See the case statement in DKIM.C:
ret = DKIM_STAT_OK;
policy = dkim_policy(dkim, &test);
switch (policy)
{
case DKIM_POLICY_SIGNSOME:
break;
case DKIM_POLICY_REQUIRED:
if (!msgsigned)
ret = DKIM_STAT_NOSIG;
break;
case DKIM_POLICY_AUTHORITY:
/* XXX -- verify signer domain and sender domain match */
break;
case DKIM_POLICY_NEVER:
if (msgsigned)
ret = DKIM_STAT_BADSIG;
break;
case DKIM_POLICY_USER:
ret = DKIM_STAT_NOTIMPLEMENT;
break;
default:
ret = DKIM_STAT_SYNTAX;
break;
}
if (msgsigned && !verified)
ret = DKIM_STAT_BADSIG;
return ret;
As you can see, the DKIM_POLICY_AUTHORITY policy is ignored.
So Mike, offering support for DKIM_POLICY_AUTHORITY is really at the very
least I am personally advocating for because without out, I believe it
lowers the technical and marketing value of DKIM-BASE and the protection it
may offer to domains who may want it.
If we can stop trying to find out WHY one will want this, and just accept
that some MIGHT want it (which I strongly believe many will), and program it
into the protocol and verifiers, such as the SENDMAIL MILTER, then it will
finally give me some reason to begin implementing this stuff.
Without, anyone can sign without restrictions and that doesn't help the
domain or the receivers one bit. We are back to the same vague NEUTRAL open
ended issues that were problematic with SPF.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html