[ietf-dkim] Mailing lists and s/mime & dkim signatures - mua considerations
MH Michael Hammer (5304)
MHammer at ag.com
Tue Aug 24 06:42:54 PDT 2010
> -----Original Message-----
> From: ietf-dkim-bounces at mipassoc.org [mailto:ietf-dkim-
> bounces at mipassoc.org] On Behalf Of Dave CROCKER
> Sent: Monday, August 23, 2010 11:06 PM
> To: Daniel Black
> Cc: ietf-dkim at mipassoc.org
> Subject: Re: [ietf-dkim] Mailing lists and s/mime & dkim signatures -
> DKIM's main purpose is assessment by reputation filtering engines.
> important reputations to assess are the entities that are
Please show us in RFC4871 where it says DKIMs main purpose is assessment
by reputation filtering engines.
In re-reading 4871 I find the following references:
6.3. Interpret Results/Apply Local Policy
It is beyond the scope of this specification to describe what actions
a verifier system should make, but an authenticated email presents an
opportunity to a receiving system that unauthenticated email cannot.
Specifically, an authenticated email creates a predictable identifier
by which other decisions can reliably be managed, such as trust and
reputation. Conversely, unauthenticated email lacks a reliable
identifier that can be used to assign trust and reputation. It is
reasonable to treat unauthenticated email as lacking any trust and
having no positive reputation.
Nothing here that begins to imply that the main purpose is assessment by
reputation filtering engines.
Perhaps this paragraph slightly down the page:
Once the signature has been verified, that information MUST be
conveyed to higher-level systems (such as explicit allow/whitelists
and reputation systems) and/or to the end user. If the message is
signed on behalf of any address other than that in the From: header
field, the mail system SHOULD take pains to ensure that the actual
signing identity is clear to the reader.
But again, no verbage that matches your assertion. The modifying clause
that begins with "such as".... gives examples but only explicitly states
that the information must be conveyed to higher level systems.
May be that you are basing your assertion on section 8.5 regarding
replay attacks.... except that begins with "Partial solutions" in
referring to reputation systems, so that can't be it.
If we look at additional DKIM related RFCs, the only explicit use of the
identifier is found in the ADSP RFC which is certainly not reputation
system based but assertion based. But I forget.... one of the authors of
that RFC says don't use it because it is bad, bad, bad.
Looking forward to your response and explanation of where we find the
main purpose of use in reputation systems in the RFC.
More information about the ietf-dkim