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

Damon <deepvoice@gmail.com> Fri, 04 August 2006 18:41 UTC

Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G94by-0004YW-Bk for ietf-dkim-archive@lists.ietf.org; Fri, 04 Aug 2006 14:41:30 -0400
Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G94bw-0002EO-W9 for ietf-dkim-archive@lists.ietf.org; Fri, 04 Aug 2006 14:41: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 k74IduAq000810; Fri, 4 Aug 2006 11:39:57 -0700
Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.233]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k74Idq53000760 for <ietf-dkim@mipassoc.org>; Fri, 4 Aug 2006 11:39:52 -0700
Received: by wr-out-0506.google.com with SMTP id 36so26033wra for <ietf-dkim@mipassoc.org>; Fri, 04 Aug 2006 11:39:23 -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=joSG70KuiZYLcEjy5NacxDCJNOakpWDKyFXgs+K+tYhxfOTtM+MtofPGxH2Mm9QrAYlfeABHBZCDRa4dSCigeAvonXhpa4TTix5I/7XCaJVkUe9zVKmycstxtvDtC8pT/jjwbDm2skGqK3TsGlOMCGWZSC1aVMtX/4iZa9IjiC4=
Received: by 10.78.127.2 with SMTP id z2mr1654108huc; Fri, 04 Aug 2006 11:39:23 -0700 (PDT)
Received: by 10.78.149.6 with HTTP; Fri, 4 Aug 2006 11:39:23 -0700 (PDT)
Message-ID: <62146370608041139q3f83d654yddb0e7471f59bd0e@mail.gmail.com>
Date: Fri, 04 Aug 2006 14:39:23 -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: <114EFFAD-100B-483B-B865-FD96CE2F1021@mail-abuse.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <20060802002353.U59653@simone.iecc.com> <44D36203.2060803@mtcc.com> <20060804112731.I21459@simone.iecc.com> <44D36B4A.2050903@mtcc.com> <20060804114527.Y27352@simone.iecc.com> <44D37376.4020408@mtcc.com> <20060804132203.Y49810@simone.iecc.com> <EAF17954-74A3-4374-A059-B31A1414B350@mail-abuse.org> <20060804140232.H49810@simone.iecc.com> <114EFFAD-100B-483B-B865-FD96CE2F1021@mail-abuse.org>
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: ea4ac80f790299f943f0a53be7e1a21a

> Imagine that policy takes the form of a list that can either be
> declared as partial or complete.  In the case of a partial list,
> although that information will not aid the blocking of messages
> outright, it can still serve to clarify genuine relationships between
> the From email-address domain and the signing domain when they
> differ.  A partial list indicates that recipients should consider the
> reputation of the signing domain instead of blocking messages when
> this relationship is not established.  On the other hand, a complete
> list indicates that recipients need not consider the reputation of
> the signing domain and can blocking messages when the relationship is
> not established.  Although a complete list offers greater utility,
> for general use a complete list is not very practical assertion for
> most domains.
>
> -Doug
>


 That is the sender suggesting how I should handle the message on a failure.
I already consider the reputation of the sending domain/ip. If I was
now going to have to start considering the reputations of signing
domains (if they are seperate) I certainly would not leave it up to
the sender to tell me how to do it... unless.. the policy list is
_always_ more restrictive.

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