[ietf-dkim] No centralized database is needed.
dotis at mail-abuse.org
Tue Aug 30 15:28:08 PDT 2005
On Aug 30, 2005, at 1:01 PM, Frank Ellermann wrote:
> I want to kill all pbaker at verisign where it's 100% clear that
> it wasn't you or somebody else @verisign. Modulo screw ups on
> your or my side, Please tell me where that misses essential
> points in the design of DKIM.
One approach could be to create a centralized database (DNS) indexed
for specific mailbox-domains that indicate signature requirements
with lists of which domains are permitted or must sign the message.
There would also need to be an agreement when a specific mailbox-
domain should invoke the application of this information.
Another approach could be to collect relationships discovered within
signed messages to determine when messages appear to be from a
different entity. The signed message may even advise what
information should be compared against the mailbox-address and
perhaps even the pretty-name. While in most cases the collected
relationships (bindings) would be made at the behest of the recipient
and require their approval, some relationships could be established
Those relationships where the mailbox/signing are the same, and where
the message advises only the mailbox/signing domain are essential to
identify the originator of a message, then capturing this
relationship should be safely done automatically. With this
information captured (cached), the MTA or MUA would be able to detect
when a message violated these expected relationships.
To recognize the originator of a message when there are no assurances
being made regarding the mailbox-address, an opaque-identifier that
tracks accounts would be added by the signing domain. This opaque-
identifier would become part of the captured relationship once
approved by the recipient. A provision would be needed to indicate
when a key had been delegated and should not be trusted to make
recommendations with respect to the scope of a binding. This
delegated key should also require the opaque-identifier to equal the
In the case of particular domain that recommends only the signing/
mailbox domains be bound, then following initial contact by anyone in
that domain, comparing the signing/mailbox domains would indicate
when the source of a message appears suspicious. If a subsequent
message appeared suspicious coming from a list server, then the
recipient could merge the list server domain within the associated
relationship. This approach would make it more advantageous for list
servers not to damage initial signatures.
Even when somebody at somedomain which allows any mailbox-domain in the
From header but signs the out-going mail, the added opaque-
identifier would still permit detecting when someone was attempting
to pretend to be that individual. This would not require the
administration of centralized database.
More information about the ietf-dkim