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

"Hector Santos" <hsantos@santronics.com> Fri, 04 August 2006 13:01 UTC

Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8zIe-0005T8-4N for ietf-dkim-archive@lists.ietf.org; Fri, 04 Aug 2006 09:01:12 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8wD2-0003xr-07 for ietf-dkim-archive@lists.ietf.org; Fri, 04 Aug 2006 05:43:12 -0400
Received: from sb7.songbird.com ([208.184.79.137]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G8w2K-0002ul-NC for ietf-dkim-archive@lists.ietf.org; Fri, 04 Aug 2006 05:32:12 -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 k749VPZ5018932; Fri, 4 Aug 2006 02:31:25 -0700
Received: from winserver.com (winserver.com [208.247.131.9]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k749VFdd018915 for <ietf-dkim@mipassoc.org>; Fri, 4 Aug 2006 02:31:15 -0700
Received: by winserver.com (Wildcat! SMTP Router v6.1.451.8) for ietf-dkim@mipassoc.org; Fri, 04 Aug 2006 05:33:18 -0400
Received: from hdev1 ([70.146.15.136]) by winserver.com (Wildcat! SMTP v6.1.451.8) with ESMTP id 1437782516; Fri, 04 Aug 2006 05:33:17 -0400
Message-ID: <011501c6b7a8$96f364c0$0201a8c0@hdev1>
From: Hector Santos <hsantos@santronics.com>
To: John L <johnl@iecc.com>, Michael Thomas <mike@mtcc.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>
Subject: Re: [ietf-dkim] A more fundamental SSP axiom
Date: Fri, 04 Aug 2006 05:30:11 -0400
Organization: Santronics Software, Inc.
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
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: 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: -2.6 (--)
X-Scan-Signature: 00e94c813bef7832af255170dca19e36

----- Original Message -----
From: "John L" <johnl@iecc.com>
To: "Michael Thomas" <mike@mtcc.com>
Cc: "DKIM List" <ietf-dkim@mipassoc.org>
Sent: Thursday, August 03, 2006 3:45 PM
Subject: Re: [ietf-dkim] A more fundamental SSP axiom


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

I know what you mean John, but that is exactly what a major part of the
problem is.

"Transit Damage" comes in many forms, and the end result is that it adds a
lower
confidence for the receiver and the recipient-user.

Who is the recipient-user going to blame first when his ISP continues to
pass junk his way?

The industry direction for ISVs is to add more direct logic in this equation
and limit pass on the responsibility or risk to the user.   This is also
being coupled with a higher pressure by policitians for the ISP to take on
more responsibility.  I haven't looked at a particular bill status since it
was introduced last year, but ISPs will be required to AVS and security
software installed or they could be fined and liable for mal-practice.  This
is not being a lawyer, but straight forward High Tech/Law/IP industry
information that any responsible CTO must be kept abreast of.

So IMV, you do have to take a look what "transmit damage" really means. I
can understand that adminstrators don't have control over this, but for the
mail mover software vendors, it does.  The goal is to get all software from
point a to z working together with a new standard to maek DKIM work.

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

If you ask all your customers the simple question, "Do you want your domain
to be protected from any illegal or malicious representation or abuse?" I am
fairly confident you will get a resounding "Yes" as an answer across the
board.  Of course, followed up with "when do I get this update?"  <g>

John, I don't think anyone wants they domain, email address abused or
misrepresented. I know for my own personal experience, as a user of my own
products, that until it started to help to me, it was the final straw and I
began to do something I was philosophically and militantly against doing for
a long time - making decisions on what mail is good or bad.  So the ethical
compromise was to purely based decisions on technical SMTP compliance
considerations and not any subjected mail content intepretations. That we
pass on to our 3rd party AVS vendors.

That's the same design approach I am taking with DKIM-BASE and SSP/DSAP.
Trying to define all the administrator "use" cases will be nearly
impossible, but one thing that can be done is to define a mechanical
protocol with some enforcement protocols that the software are expected to
follow.  In my view, this isn't a hard problem. Complex? Probably expensive?
Requires coordination? Maybe, but not hard.  DKIM-BASE lays the ground work,
so now we need to see what it will take to make it work so that people will
begin to implement it.  Thats the problem to solve it.

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


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