ietf-dkim
[Top] [All Lists]

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

2006-11-26 14:52:52
william(at)elan.net wrote:

That said I was referring to WG not being interested in working out
mail list cases (which was always the DK's problem) which would
involve signature that is more likely to path through (and still
be verifiable after) mail lists and similar redirectors and working
out policy system that takes existence for such redirectors and
that some domain users often use them into account.

I agree with your comments.

As I outline in many of my technical postings, I tried to see what it will take at a minimum to make DKIM fit into a LS environment and still offer the highest possible DKIM protection.

What this is means is what do I have to change in our LS to make DKIM work "at a minimum."

I don't see how you can do this without considering SSP as a "Controlling" concept.

The simplest is a LS preventing the usage of a mailing list for a highly exclusive DKIM/SSP domain. To me, that is paramount. We must satisfy this requirement first.

    - LS should check SSP during the subscription process to make sure
      a domain is not restrictive.

We must work on the basis that a DOMAIN may want to use DKIM in a highly exclusive, bar none, 1 to 1 communications environment only. That is the highest protection DKIM an offer. We can't ignore this.

After that, it gets relaxed and murky as to how to keep this DKIM security intact with various relaxed conditions. But we must satisfy the ideal condition and that is the strong and/or exclusive SSP policy.

At this point, we then look at new features to support the DKIM LS implementation such as:

  [_] Do not change subject line for DKIM signed mail
  [_] Do not change BODY for DKIM signed mail.

In sure a scenario, the LS becomes a pure distribution/passthru like system. Keep in mind that thus far, its not about a LS resigning mail. But first preventing errors and maintaining mail integrity first.

But what if the admin wants to "alter" the message, at this point, we are talking about resigning concepts with a bunch of new options to handle this.

So it gets really crazy in order to do this correctly.

---
HLS






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

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