Thomas You raised good points, but I don't think it is that complex at all.
We have a mailing list server (MLS) product and I feel that if we want to accomodate DKIM, there are some things that we can do: - The MLS should use SSP to pre-emptive email subscribers with restrictive domains. This would be done at the subscription level. It will help protect the domain owner from any possible malicious abuse from their own employees, users, students, or bad actors. - If the MLS is prepared for signing, it should use SSP to determine which domains allow it. - If the domains allows it, the MLS should be allowed to STRIP broken signatures or signatures it will break by resigning and then resign itself. NOTE: This is currently against DKIM-BASE specification (No stripping). In short, iff the DOMAIN doesn't care about the potential abuse of its domain by promiscuously or blindly sending it to a MLS, then the DOMAIN should be explicit with relaxed SSP policies saying it really doesn't care or not use DKIM at all for this particular mode of operation. At this point, the receiver will treat it like any other mail because the DOMAIN simply doesn't care one way or another. To me, it doesn't make sense for an organization to invest in a new SECURITY framework only to leave the key under the "Porch Potted Plant" thus breaking its own new DKIM security policies for the organization. (See ** below) With just DKIM-BASE, the threats are well documented. See the TA draft. SSP is about offering a possible solution, if only partial, to this problem. The main issue is feasibility. If you want DKIM to work via a MLS, then I think it is naive to believe (speaking in general) it will work very well without some sort of MLS change to consider the redistribution process of original DKIM signed mail. ** Take for example this mailing list: There are signatures here from various people; Mike, Jim, Arvel, etc. Guess what? All of them will fail the DKIM test because the mailing list server hosting IETF-DKIM is breaking the integrity of the message without correcting it. Yet we continue the downlinks ignore it and accept it - the CRY WOLF syndrome. What is to prevent the BAD ACTOR to use this "cry wolf", borrowing Mike's, Jim's, etc signature and use it in ATTACKING other systems? Or even here, how will I know that the post here from Jim or Mike actually come from them? In short, what this will promote is a damage DKIM concept where receivers will ignore DKIM altogether just like users ignore Popup Errors from MUA saying a SMIME/PGP message has failed. This is what you want to avoid. -- Hector Santos, Santronics Software, Inc. http://www.santronics.com ----- Original Message ----- From: "Thomas A. Fine" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Monday, September 11, 2006 2:57 PM Subject: [ietf-dkim] SSP and mailing lists > Some here have proposed adding a clause statement to the > standard all-signed policy that waters it down to effectively > mean that receivers might get valid messages damaged by > gateways, and adds a new policy that says a domain guarantees > it's addresses will not go through non-compliant gateways. > > The standard policy becomes to weak. It doesn't mean anything > besides "please accept mail that looks like it might be from us. > It means the domain remains unprotected. > > And who could set the stricter policy? The odd bank or tightly run > corporate entity maybe. Who could not? Universities, ISPs, email > address providers, technical corporations -- all these groups expect > their users to have some amount of freedom participating in mailing > lists. > > So if the only way a domain can set a policy that permits* recipients > to drop unsigned or broken mail is to set a policy that it will > not use non-compliant mailing lists, then this is doomed to failure, > and I would go so far as to say that nobody would bother with DKIM > at all, because they couldn't use it to protect their domains. > > One serious point about a policy such as the one described above is that > it seems to attempt to describe the transitional state of the entire > internet, rather than the transitional state of a particular site. As > such, almost no one could have any other policy besides this until DKIM > acceptance approached 100%. > > Maybe this is just a question of wording. Perhaps everyone would be > satisfied with these two policies: > > "I sign all email" > > "I sign all email, and do NOT permit email through any body or > signature altering gateways" > > Now this might accomplish what is desired, but it reads entirely > differently. The first is still strong, not weakened as has been > suggested. And they describe what the site does, not what the > internet is doing. The second statement is very strong. It > may be rarely used but I can see it's utility. It would probably > be more useful on a per-address basis than it would be on a > per-domain basis. > > First, note that basically what this almost seems to be saying is that > the envelope-from must match the From: and/or DKIM address. > > Second, note that this may only useful in a policy-first environment. > In the current spec, the assumption is we never know the policy if we > have a valid key. So without gutting and reworking that fundamental > concept (which might be a good thing), such a policy of more strict > email control is not really implementable. > > So basically, I think that policy should be designed for the long > term steady state, and not designed primarily for a transition > period. The implementors can take care of the transition. > > tom > > * another spin on who dictating versus recommending versus asking is > this: an all-signed policy gives the sending domain's _blessing_ to > the receiver to drop the mail on the floor if it is not verifiable. > It doesn't say they have to do it, but it says that it is fine to > do that. _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
