[ietf-dkim] DKIM Threat Analysis v0.06

[Scott Kitterman]

Arvel Hathcock wrote:
>> Is it a tool for the SMTP server to reject messages from SMTP clients 
>> that are doing something unauthorized?  Is it a tool for 
>> post-acceptance filtering and routing in the MDA?  Is it a tool meant 
>> to give MUAs information to display to end users?
> 
> 
> In my implementation, the SMTP server does all the DKIM checking and 
> either rejects the message outright or documents the results in an AR 
> header. Assuming the message isn't rejected, my MTA router code, which 
> invokes my filters, add/subtracts from the heuristic scoring, etc based 
> on what it finds in the AR header.  Finally, under precise conditions my 
> web-based MUA will display a notice along the lines of what Yahoo is 
> doing.  This also is triggered by the AR header.  The key for me is to 
> do the DKIM checking during the SMTP session and document the results in 
> an AR header for use later down the processing chain (MTA/MUA) - this is 
> just how my particular implementation does it, your mileage may vary :)
> 

IMO, this is exactly how it should be done.

Now I think this example may provide a useful point for discussing the 
bounds of what the working group ought to tackle.

You've got an SMTP time MTA component the does the actual DKIM check, 
makes an decision to accept responsibility for delivery of the message, 
and documents the results.

You've got an MDA performing filtering and deciding where to deliver the 
message.

You've got an MUA that, if appropriate, displays the result documented 
by the MTA.

The MTA component of your architecture is, I think, what needs to be 
designed in detail by the working group to support interoperability. 
The MDA/MUA parts I'm not so sure about.  My view would be that there 
should be some general guidance about how to go about these things in 
the working group output, but that detailed designs aren't necessary. 
Perhaps not even that.  Perhaps the WG just does the SMTP part?

Scott Kitterman