IETF Logo Mail Archive

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

Damon <deepvoice@gmail.com> Sat, 05 August 2006 02:06 UTC

Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9BYx-0006kT-Bi for ietf-dkim-archive@lists.ietf.org; Fri, 04 Aug 2006 22:06:51 -0400
Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G9BYv-0003yj-V7 for ietf-dkim-archive@lists.ietf.org; Fri, 04 Aug 2006 22:06:51 -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 k75227Pm023562; Fri, 4 Aug 2006 19:02:08 -0700
Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.185]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k7521tj5023536 for <ietf-dkim@mipassoc.org>; Fri, 4 Aug 2006 19:01:56 -0700
Received: by nf-out-0910.google.com with SMTP id g2so627532nfe for <ietf-dkim@mipassoc.org>; Fri, 04 Aug 2006 19:01:29 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ZvzOgpM8fVr4qvHKY0Q9ZmbGCsPv4nZQ7rh0H6FAnUqGLVzYYqYAOak+2ajTHwjNfbLrTO2l4hqeouHPGMiYAbZnqc0WCjLHCtxtn0YtVH2MZriGVho45eLBOpGveoeS4Geber9hOgtAsK02kDQms8lrDf5nPWy4ri+H9ewh66s=
Received: by 10.78.175.14 with SMTP id x14mr1785661hue; Fri, 04 Aug 2006 19:01:29 -0700 (PDT)
Received: by 10.78.149.6 with HTTP; Fri, 4 Aug 2006 19:01:29 -0700 (PDT)
Message-ID: <62146370608041901r32279846n1ec2afac1c79d3b2@mail.gmail.com>
Date: Fri, 04 Aug 2006 22:01:29 -0400
From: Damon <deepvoice@gmail.com>
To: Douglas Otis <dotis@mail-abuse.org>
Subject: Re: [ietf-dkim] A more fundamental SSP axiom
In-Reply-To: <F307EB7D-3600-4AE3-8D67-EF2F012A8BA7@mail-abuse.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <MDAEMON-F200608041910.AA1025596md50000023428@altn.com> <62146370608041731ufd927v8d66be5459ea8982@mail.gmail.com> <F307EB7D-3600-4AE3-8D67-EF2F012A8BA7@mail-abuse.org>
X-Songbird: Clean, Clean
Cc: "ietf-dkim@mipassoc.org" <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: e1e48a527f609d1be2bc8d8a70eb76cb

I really like William and Douglas's ideas...
Is there anyone who doesn't?


Damon

On 8/4/06, Douglas Otis <dotis@mail-abuse.org> wrote:
>
> On Aug 4, 2006, at 5:31 PM, Damon wrote:
>
> > On 8/4/06, Arvel Hathcock <arvel.hathcock@altn.com> wrote:
> >> > Yes but.. I don't think that everyone is going to be aware of
> >> the risk > or ignore it thinking it can't happen to them.
> >>
> >> Quite the contrary really, I'd think.  And anyway, are we to
> >> remove from our work even useful things on the basis that there
> >> are some who might not understand it?  Surely not.  We should just
> >> do our best to document what we can to help them.
> >
> > Nothing contrary about it... I wish I had a nickle for everyone
> > that set their SPF records with a ~all. I also think that this
> > would be of diminishing returns. They may set it up this way.. but
> > the first problem (or second) they have, it will get turned off.
> > Then what is their alternative? I don't dislike the idea and if it
> > were released this way... at least I could say I told you so. I am
> > just hoping we can come up with a solution that will have a safety
> > or 'Plan B' attached.
>
> This Plan B will stop more abuse than you can imagine:
>
> Require that all DKIM clients use a "_dkim.<host-name>" that can be
> verified with a simple Address record lookup.  Define a DKIM client
> policy that can assert "ONLY SEND SIGNED DKIM MESSAGES."  A client
> that does not authenticate or does not sign with DKIM can then be
> blocked.
>
> -Doug
>
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

v2.23.0 | Report a Bug | By Email