Re: [ietf-dkim] A more fundamental SSP axiom

"Hector Santos" <hsantos@santronics.com> Sat, 05 August 2006 03:00 UTC

Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9COU-0002np-R6 for ietf-dkim-archive@lists.ietf.org; Fri, 04 Aug 2006 23:00:06 -0400
Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G9COT-0000tq-EC for ietf-dkim-archive@lists.ietf.org; Fri, 04 Aug 2006 23:00:06 -0400
Received: from sb7.songbird.com (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k752uCb2029632; Fri, 4 Aug 2006 19:56:12 -0700
Received: from winserver.com (news.winserver.com [208.247.131.9]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k752u0YE029609 for <ietf-dkim@mipassoc.org>; Fri, 4 Aug 2006 19:56:00 -0700
Received: by winserver.com (Wildcat! SMTP Router v6.1.451.8) for ietf-dkim@mipassoc.org; Fri, 04 Aug 2006 22:58:07 -0400
Received: from hdev1 ([72.144.136.116]) by winserver.com (Wildcat! SMTP v6.1.451.8) with ESMTP id 1500471407; Fri, 04 Aug 2006 22:58:06 -0400
Message-ID: <02a601c6b83a$7c819980$0201a8c0@hdev1>
From: Hector Santos <hsantos@santronics.com>
To: Mark Delany <MarkD+dkim@yahoo-inc.com>, ietf-dkim@mipassoc.org
References: <MDAEMON-F200608041905.AA0542108md50000023415@altn.com><44D3E5C9.5050408@mtcc.com> <20060805011337.73202.qmail@snake.corp.yahoo.com>
Subject: Re: [ietf-dkim] A more fundamental SSP axiom
Date: Fri, 04 Aug 2006 22:54:32 -0400
Organization: Santronics Software, Inc.
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Songbird: Clean, Clean
Cc:
X-BeenThere: ietf-dkim@mipassoc.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF DKIM Discussion List <ietf-dkim.mipassoc.org>
List-Unsubscribe: <http://mipassoc.org/mailman/listinfo/ietf-dkim>, <mailto:ietf-dkim-request@mipassoc.org?subject=unsubscribe>
List-Archive: <http://mipassoc.org/pipermail/ietf-dkim>
List-Post: <mailto:ietf-dkim@mipassoc.org>
List-Help: <mailto:ietf-dkim-request@mipassoc.org?subject=help>
List-Subscribe: <http://mipassoc.org/mailman/listinfo/ietf-dkim>, <mailto:ietf-dkim-request@mipassoc.org?subject=subscribe>
Sender: ietf-dkim-bounces@mipassoc.org
Errors-To: ietf-dkim-bounces@mipassoc.org
X-SongbirdInformation: support@songbird.com for more information
X-Songbird-From: ietf-dkim-bounces@mipassoc.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793

From: "Mark Delany"


> And are we talking about Mailing Lists today, or Mailing Lists in five
> years time after DKIM slowly ramps up? A Mailing List of the future
> mail well be verifying incoming mail and make decisions about
> re-broadcasting based on "I sign all"?

Very good point.

For me, it is almost a no-brainer of what we will need to add our mailing
list server on the onset.  To reduce all kinds of issues from support,
survivability questions, including reduce liability,  these two features
will help:

1)  Check for restrictive policies during subscription process, accept
     only non-DKIM domains or those that might allow 3rd party signing
     depending if the MLS signing option is enabled.

2)  Offer new options to avoid mail integrity changes (adding Header and
     Footers) based on DKIM messages.

The last one is very tough because most people are going to want to add
footers, so that pretty much dictates one or more two things:

    - The domain allows 3rd party signing, and/or even possibly
    - The domain allows stripping of the original.

Stripping I believe violates DKIM-BASE so that's something that should be
reconsidered.   Stripping fits well with a policy such as:

       OP=optional;3P=optional;    Both Party may sign

But if the MLS is intent in signing the mail, it will be difficult for MLS
to support:

        OP=NEVER; 3P=NEVER;    No signing expected
        OP=ALWAYS; 3P=NEVER;   1st party only always signs mail
        OP=OPTIONAL; 3P=NEVER;  1st party may sign mail

So the domain itself has to be aware of what it doing with its DKIM mail.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com





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