At 09:23 01-06-2007, Michael Thomas wrote:
I have to say that I don't understand that paragraph at all. That,
and some other messages in this thread seem to suggest that auth-res
is only for MUA's consumption. I don't think that's the case at all,
and that the draft needn't pick who should and shouldn't use the
information -- only make clear the security considerations of when
it ought to be deemed trustworthy.
From what I read in the draft, auth-res can be used by the MUA and
by filters. The header is only useful when the results are conveyed
by filters which we trust. Picking who should and shouldn't use the
information can be seen as a security consideration. Maybe the
paragraph can be reworded as John brought up a case where the header
is useful even if it was not inserted prior to delivery.
As an example, our implementation saves the auth-res in our MTA logs
and a grinder goes through those logs to generate stats, including
verification stats. This is arguably the same MTA that's reusing its
own auth-res :) This and other uses should be perfectly legal and
That shouldn't be a problem as it is your header and you can trust
it. I shouldn't use the auth-res header in your email, for example,
as it is outside my trust boundary. Once usage is widespread, we may
see the auth-res header being spoofed.
Regards,
-sm
_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html