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

Douglas Otis <dotis@mail-abuse.org> Thu, 03 August 2006 21:15 UTC

Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8kXD-0002F6-L7 for ietf-dkim-archive@lists.ietf.org; Thu, 03 Aug 2006 17:15:15 -0400
Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8kXC-0000ie-6N for ietf-dkim-archive@lists.ietf.org; Thu, 03 Aug 2006 17:15:15 -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 k73LDJlC016839; Thu, 3 Aug 2006 14:13:20 -0700
Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k73LD1w9016770 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ietf-dkim@mipassoc.org>; Thu, 3 Aug 2006 14:13:02 -0700
Received: from [168.61.10.151] (SJC-Office-DHCP-151.Mail-Abuse.ORG [168.61.10.151]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id k73LCUlm014430 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 3 Aug 2006 14:12:31 -0700
In-Reply-To: <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> <20060803153457.X33570@simone.iecc.com>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <4D98AB61-A542-4069-9140-9EE28EC26628@mail-abuse.org>
Content-Transfer-Encoding: 7bit
From: Douglas Otis <dotis@mail-abuse.org>
Subject: Re: [ietf-dkim] A more fundamental SSP axiom
Date: Thu, 03 Aug 2006 14:12:37 -0700
To: John L <johnl@iecc.com>
X-Mailer: Apple Mail (2.752.2)
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.0 (/)
X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5

On Aug 3, 2006, at 12:45 PM, John L wrote:

>>> "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.

A method to indicate whether other services might be employed that do  
not retain the integrity of the signature and then do not sign or  
sign with a non-designated domain, or originate the message and then  
do not sign or sign using a non-designated domain would be helpful.   
Those with heavily phished domains may be willing to forego these  
related services that are producing such results.  A stipulation  
indicating such abstinence would be useful to the recipient.


> 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.

When DKIM signing is offered by large ESPs, it would be in their  
interest to take the steps to securely authenticate and verify  
reception of the From address prior to use.  This extra effort would  
allow autonomous management of the email-address domain's  
relationship with that of this provider.  Those DKIM providers taking  
the extra step of confirming reception should attract more users and  
gain greater delivery acceptance.  This would also expand DKIM's  
coverage of From email-addresses at a faster rate.

The administrator for a law office could make a policy assertion that  
their "DKIM-SAFE" provider is a designated signing domain.  This  
would permit their staff to make use of this provider.  The law  
office would then be relieved from setting up outbound services or  
making complex arrangements.  A requirement that the From domain  
matches the signing domain could be supplanted by a policy statement  
that lists the "DKIM-SAFE" provider as a designated signing domain.

There would be no need to arrange zone delegations, or exchange  
selector and key information on a regular basis for this to work.  A  
designated signing domain that authenticates and confirms reception  
of the From email-address should be adequate.  This would be in lieu  
of separately establishing DKIM signing or the outbound provider  
selecting prearranged key/domain combinations to enforce From/signing  
domain alignment.

As far as reputation is concerned, there is safety in numbers.  DKIM  
done the right way should also reduce abusive traffic.  Unusual  
confirmation activity could warn that someone may be attempting to  
abuse their service.  Clean-up could be expunging the offending  
confirmed email-address and recommending a scrub to the user owning  
the account.

-Doug


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