James A. Donald:
> > One way of doing this would be for the MTA to insist
> > on a valid signature when talking to certain well
> > known MTAs, and then my MUA could whitelist mail
> > sent from those well known MTAs

Paul Hoffman wrote:
> Yes, if you are willing to throw out messages whose
> signatures are broken during transit.

Signatures should not be broken when transmitted
directly from the signing MTA to the receiving MTA.  If
they are, then there is a bug in the signing or the
receiving MTA, in which case the offending party has the
ability and incentive to fix the bug.  Signatures are
likely to be broken when the signature is being checked
by the MUA, because an MTA that knows nothing about
signatures will probably break them, but an MTA that
knows to check signatures should know not to break them.

James A. Donald:
> > In short, I am not able to get any advantage out of
> > using this protocol, which means that there is no
> > advantage in sending me signed mail.

Paul Hoffman wrote:
> And there is no disadvantage either. There is
> advantages for sending signed mail to users who have a
> different threat model than you have,

I don't think anyone is a different position to me. DKIM
is usable in principle, but I am not able to benefit
from it in practice.  If I am not able to benefit from
it in practice, who is?

DKIM would be a good idea if done right.  It does not,
in fact, seem to be working at present.

Part of the problem is that part of the whitelisting
task has to be done on the MTA, and part on the MUA, and
no one has made any provision for keeping them in sync.
Seems to me, that DKIM, as implemented, implements the
high tech part of the solution, but not the actual nuts
and bolts details of the solution.

As with so many specifications, the DKIM spec is both
overspecified and underspecified - too much fluff and
bullshit, but missing essentials.

         James A. Donald

The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Reply via email to