ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Re: ISSUE: Better definition of "DKIM signing complete" required

2006-11-28 07:35:52
Charles Lindsey wrote:
On Mon, 27 Nov 2006 17:43:33 -0000, Hector Santos

The 5th item is STRIP and RESIGN as 3rd party

The 6th item is STRIP and RESIGN as 1st party in behalf of the original domain.

The difference in those last two is that they STRIP the old signature, I presume? Why should that help? Throwing away possibly useful information is not usually beneficial.

It depends on what you consider useful. Is failure useful?

First note, currently the DKIM-BASE specs make stripping a crime and
failure a disappearing act.

In principle, the goal is to keep the mail integrity intact. For a
middle ware environment such as a List Server, stripping may be the only
viable option because when you add another signature (due to alterations made), you will end up with a failure and a success.

It depends on how mixed failure and success is interpreted.  DKIM-BASE
says as long as one signature is valid in a multi-signature message, the
message is valid.  Failures MUST be ignored as if it was never signed.

There is something not very kosher with that.  I find that to be a
fundamentally flawed concept prune to exploitations.  As you note next,
there needs to be some cooperation in what is expected or is allowed.

The last one, presumably, requires cooperation between the list admin and the original domain.

Correct, and my proposal is this cooperation is done via SSP.

But too much to expect for  the average domain and the average list.

Nothing average about DKIM and in a small way, I think that has
contributed to the lack of consensus in a few areas. We are trying to
make a DKIM, a mail integrity technology, an "average" part of the
entire mail process and is nearly nearly impossible without a total system revamp of all the different mail processors. Its like trying to make DKIM work with UseNet. :-)

---
HLS


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

<Prev in Thread] Current Thread [Next in Thread>