[ietf-dkim] Modified Introduction text forrfc4871-errata (resend)

[Murray S. Kucherawy]

> Any reputation assessment system should not:
> 
> 1) limit what is to be assessed.

The proposed text does not put any limits on what gets assessed.  If an assessor wants more information, it is free to use a verifier that provides more information.

> 2) allow inclusion of un-assessed information used to provide
> annotation!

That's out of scope, since the annotation is not placed by the verifier, which is what we're discussing.

> This statement is wrong because:
> 
> 1) Any white-listing practice based upon replayable signatures _will_
> be abused.

That also seems to be out of scope to me, since it's not in the realm of the verifier.

> 2) Use of the i= value is being defined as permission to discard email!

That also seems to be out of scope to me, since it's not in the realm of the verifier.

> What interface, the presentation layer?

A DKIM API, which I suppose would live in the presentation layer.

> 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
> the requirement.
> Such an API can avoid the inter-operational problems your change will
> create.

So you are seeking to make delivery of "i=" a third mandatory output for a compliant DKIM verifier?  I believe there is already consensus against the "mandatory" part of that.

> The TCP socket does not acknowledge TCP packets and then discard them
> before being presented, and yet this is the change being advocated. :^(

That would be a protocol detail that's hidden from the user, and thus not relevant to an API specification such as the one we're discussing.