ietf-dkim
[Top] [All Lists]

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

2009-06-17 14:00:57
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.


_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html