Charles Lindsey wrote:
On Sun, 26 Nov 2006 21:37:37 -0000, Hector Santos
<hsantos(_at_)santronics(_dot_)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
participate.
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
domain.
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.
---
HLS
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html