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
_______________________________________________
ietf-dkim mailing list
http://dkim.org