[ietf-dkim] Modified Introduction text forrfc4871-errata (resend)
dotis at mail-abuse.org
Wed Jun 17 10:13:25 PDT 2009
On Jun 17, 2009, at 8:08 AM, Dave CROCKER wrote:
> So, here's a suggested merging of the two:
> This currently leaves signers and assessors with the potential for
> making different interpretations between the two identifiers and may
> lead to interoperability problems. A signer could intend one to be
> used for assessment, and have a non-reputation intent in setting the
> value in the other. However the verifier might choose the wrong value
> to deliver to the assessor, thereby producing an unintended (and
> inaccurate) assessment.
Can you provide examples of interoperability problems?
Any reputation assessment system should not:
1) limit what is to be assessed.
2) allow inclusion of un-assessed information used to provide
The change being recommended reduces intended protections.
> This update resolves that confusion. It defines additional, semantic
> labels for the two values, clarifies their nature and specifies their
> relationship. More specifically, it clarifies that the identifier
> intended for delivery to the assessor -- such as one that consults a
> white list -- is the value of the "d=" tag. However, this does not
> prohibit message filtering engines from using the "i=" tag, or any
> other information in the message's header, for filtering decisions.
This statement is wrong because:
1) Any white-listing practice based upon replayable signatures _will_
2) Use of the i= value is being defined as permission to discard email!
This is creating an operational problem by having email is accepted
and then having it discarded. This creates a disincentive for signers
to offer additional intra-domain information.
> So, this Update clarifies the formal interface to DKIM, after
> signature verification has been performed. It distinguishes DKIM's
> internal signing and verification activity, from its standardized
> delivery of data to that interface.
What interface, the presentation layer?
> The focus of the Update is on the portion of DKIM that is much like
> an API definition. If DKIM is implemented as a software library for
> use by others, it needs to define what outputs are provided, that is,
> what data that an application developer who uses the library can
> to obtain as a result of invoking DKIM on a message.
> This Update draft defines the output of that library to include the
> yes/no result of the verification and the "d=" value.
It would be inherently unsafe to intentionally ignore information used
for presentation. As such, the i= value (or its default) SHOULD be
assessed. It can be and I'll be happy to describe an API that meets
Such an API can avoid the inter-operational problems your change will
> This does not state what the implicit value of "i=" is, relative to
> "d=". In this context, that fact is irrelevant.
The i= value clarifies the entity on whose behalf the signature was
added, and directs annotation process. The d= value is irrelevant to
an assessment of behavior history, especially when the d= value might
combine the behaviors of millions. This change to DKIM is simply
wrong, since the goal of DKIM is to defend against spoofing. This
change invites massive intra-domain spoofing.
> Another example is the difference between the socket interface to
> TCP versus the TCP protocol itself. There is the activity within the
> protocol stack, and then there is the activity within in the software
> libraries that are actually used.
The TCP socket does not acknowledge TCP packets and then discard them
before being presented, and yet this is the change being advocated. :^(
Measures that email must take to fend off massive abuse should not
then result in email becoming even more unreliable.
Public MTAs (port 25) should explicitly declare an intent to issue
email. It may not be too late to resurrect your CVS effort. Once
public MTAs can be identified and consolidated, the overall size of
public MTA assessments is likely around 8 million. This would exclude
servers that depend upon email for monitoring purposes. These sources
will likely require specific ACLs.
Anti-abuse schemes that attempt to redirect assessments to customers
of public MTAs will not scale, especially when they involve dozens of
transactions. Each transaction or cryptographic operation will be
abused a million fold.
More information about the ietf-dkim