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

John L <johnl@iecc.com> Thu, 03 August 2006 19:46 UTC

Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8j9K-0008J9-UP for ietf-dkim-archive@lists.ietf.org; Thu, 03 Aug 2006 15:46:30 -0400
Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8j9I-00006F-G9 for ietf-dkim-archive@lists.ietf.org; Thu, 03 Aug 2006 15:46:30 -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 k73JjtIO002934; Thu, 3 Aug 2006 12:45:55 -0700
Received: from xuxa.iecc.com (xuxa.iecc.com [208.31.42.42]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with SMTP id k73JjmrZ002890 for <ietf-dkim@mipassoc.org>; Thu, 3 Aug 2006 12:45:48 -0700
Received: (qmail 3826 invoked from network); 3 Aug 2006 19:45:22 -0000
Received: from simone.iecc.com (208.31.42.47) by mail2.iecc.com with QMQP; 3 Aug 2006 19:45:22 -0000
Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 3 Aug 2006 19:45:22 -0000
Date: Thu, 03 Aug 2006 15:45:22 -0400
From: John L <johnl@iecc.com>
To: Michael Thomas <mike@mtcc.com>
Subject: Re: [ietf-dkim] A more fundamental SSP axiom
In-Reply-To: <44D24A20.6050109@mtcc.com>
Message-ID: <20060803153457.X33570@simone.iecc.com>
References: <20060802002353.U59653@simone.iecc.com> <44D0E259.7040400@mtcc.com> <20060802165510.X1168@simone.iecc.com> <44D160BD.7080209@mtcc.com> <20060802223619.E86316@simone.iecc.com> <44D24A20.6050109@mtcc.com>
Cleverness: None detected
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
X-Songbird: Clean, Clean
Cc: DKIM List <ietf-dkim@mipassoc.org>
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.1 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9

>> "I sign all mail" ...

> As I've said before, there are really two different subclasses of this one.
> You can have your mail very well under control, but you don't have
> control over what the damage might be in transit. For some people
> like banks and phishing targets, that collateral damage is likely to be
> acceptable. For most everybody else it's not.
>
> So I guess it just intrinsically bugs me that the former is a pretty rarified
> class  of sender, and is SSP really _only_ for them? (leaving I send
> no mail aside).  Is there little or no value in knowing that you sign
> everything, but transit related damage is possible?

We have to keep in mind that the recipient is interpreting this stuff, and 
it's up to the recipient to decide what risk they are willing to accept. 
Transit damage is always possible, so I don't see any value in pointing 
that out.  As a receiver, I find a hint that unsigned mail from you is 
probably bogus to be useful.  Your own opinion of the value of that mail 
is not.

I also don't see "I sign everything" as limited to large companies.  My 
lawyer is part of a small firm with their own mail server on a leased 
line.  I expect they have enough sense to tell people that if they want to 
send mail from home or on the road, use the company's web mail.  They'd be 
a perfectly good candidate for "I sign everything", and I don't think 
they're at all atypical.

> But it shouldn't hurt to just add stuff to the policy record -- possibly 
> non-standard experimental stuff -- and if it's useful and relevant, 
> users of the protocol will almost certainly have an incentive to upgrade

Experiments are always a good idea, which is why it's important to be able 
to mix in experimental stuff without breaking other software.  (See, for 
example, X-foo: headers in mail messages.)  I just don't want to 
standardize stuff prematurely and find out that it's not what people need.

Regards,
John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://johnlevine.com, Mayor
"I dropped the toothpaste", said Tom, crestfallenly.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html