ietf-mailsig
[Top] [All Lists]

RE: MASS/DKIM BOF Summary

2005-08-05 13:31:54



From: owner-ietf-mailsig(_at_)mail(_dot_)imc(_dot_)org 
[mailto:owner-ietf-mailsig(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Earl 
Hood

All of these are from a domain-centric perspective, and 
excludes the author/sender perspective, formally known as 
Originating Address (OA) in the DKIM SSP draft.

If DKIM is intended to deal with things at a user-level, then 
user-level considerations must be addressed, especially 
spoofing (which can also have an affect on domains).

My feeling is that anyone who builds a DKIM solution is going to do so
in two halves. The first is a module that is centered on signature
verification, checking policy compliance etc, the machinery of the
crypto.

The second module would obtain, maintain and process reputation data
associated with particular signing domains. One way to build such a
module out of just the core DKIM spec would be to look at the past
behavior of the domain, as measured by criteria such as success rate
passing the spam filter, the fact that outbound messages are sent to
that domain, length of time the domain had been registered etc.

Such a module would probably contain its own independent cache and talk
to the DNS directly as well as having the ability to retrieve data from
other data sources (accreditation/reputation) and assimilate it.

I would expect that in a large installation the domain scoring module
would be a shared resource across a large number of servers. Although
for performance reasons it might well be advantageous for an
implementation to involve some form of local cache at the server end for
storing the most commonly accessed results.


One question I have here is the level of implementation detail people
feel is appropriate. I do not generally give implementation detail in
specifications. The architecture above is how I would make use of the
information in a large scale system. I do not see an immediate need to
standardize the protocol interfaces between the server and the protocol
module, nor would it be reasonable for DKIM to consider this in scope if
there was such a need.

<Prev in Thread] Current Thread [Next in Thread>