[ietf-dkim] Re: ISSUE: Better definition of
"DKIM signing complete" required
hsantos at santronics.com
Mon Nov 27 09:43:33 PST 2006
Charles Lindsey wrote:
> On Sun, 26 Nov 2006 21:37:37 -0000, Hector Santos
> <hsantos at santronics.com> wrote:
>> 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:
> AFAICS, a List Expander has the following options:
> 1. Ignore DKIM. Pretend it doesn't exist.
> The result of that is that list members (or their ISPs) will start
> regarding some messages with "suspicion", and maybe drop them. List
> members wll not be pleased.
> 2. Refuse to subscribe (as contributors) sites with exclusive SSP policies.
> Will work, but will piss off people from such domains who want to
> 3. Manage the list so that signatures still work after passing through.
> I.e. don't change 'critical' headers, don't add stuff at the end of
> bodies, etc.
> 4. Resign all messages yourself.
> Essentially, you are saying "I realise I may have broken the existing
> signature, but I assure you I verified the original signature and
> checked that it complied with the sender's SSP, and my new signature
> encompasses an X-verified header I added to testify to those checks.
> Trust me! I am a Good Guy!"
> And then you hope that your reputation is good enough that your
> highly suspicious recipients will indeed believe that you are a "Good Guy".
> So, is that a good summary of strategies that have been discussed on
> this list, or are there others? And are they good enough (#4 seems the
> best approach to be, or maybe #3 and #4 together)?
I think #1 include those who are just unaware of DKIM, legacy software.
I think #2 is the most practical support and probably most likely the
first thing a list server author will do. I'm speaking as one. I think
this is something all "signup concepts" will look at because it is very
easy to do and helps "Email/Signup Verification" process.
I think once the decision is made to support DKIM, which inherently
includes #2, is to begin offering options to not alter the integrity
(#3) and also offer resigning (#4) when possible.
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
So there are all known or already discussed scenarios. These was
written in various places, including the DSAP I-D.
However, the key, IMTO, is SSP. All middle ware interfacing is only
technically and consistently correct if the DOMAIN allows for 3rd party
senders and/or 3rd party DKIM resigning, fingerprints.
More information about the ietf-dkim