RE: [Asrg] CRI Header

"Eric D. Williams" <> Wed, 04 June 2003 02:33 UTC

Received: from ( [] (may be forged)) by (8.9.1a/8.9.1a) with ESMTP id WAA04876 for <>; Tue, 3 Jun 2003 22:33:24 -0400 (EDT)
Received: (from mailnull@localhost) by (8.11.6/8.11.6) id h542X0d20917 for; Tue, 3 Jun 2003 22:33:00 -0400
Received: from ( []) by (8.11.6/8.11.6) with ESMTP id h542WxB20914 for <>; Tue, 3 Jun 2003 22:32:59 -0400
Received: from ietf-mx ( []) by (8.9.1a/8.9.1a) with ESMTP id WAA04867; Tue, 3 Jun 2003 22:32:53 -0400 (EDT)
Received: from ietf-mx ([]) by ietf-mx with esmtp (Exim 4.12) id 19NO3O-0005QF-00; Tue, 03 Jun 2003 22:31:06 -0400
Received: from ([] by ietf-mx with esmtp (Exim 4.12) id 19NO3N-0005QC-00; Tue, 03 Jun 2003 22:31:05 -0400
Received: from (localhost.localdomain []) by (8.11.6/8.11.6) with ESMTP id h542VMB20847; Tue, 3 Jun 2003 22:31:22 -0400
Received: from ( []) by (8.11.6/8.11.6) with ESMTP id h542UWB20778 for <>; Tue, 3 Jun 2003 22:30:32 -0400
Received: from ietf-mx ( []) by (8.9.1a/8.9.1a) with ESMTP id WAA04729 for <>; Tue, 3 Jun 2003 22:30:26 -0400 (EDT)
Received: from ietf-mx ([]) by ietf-mx with esmtp (Exim 4.12) id 19NO10-0005OP-00 for; Tue, 03 Jun 2003 22:28:38 -0400
Received: from ([] by ietf-mx with smtp (Exim 4.12) id 19NO10-0005NL-00 for; Tue, 03 Jun 2003 22:28:38 -0400
Received: from red (unverified []) by (EMWAC SMTPRS 0.83) with SMTP id <>; Tue, 03 Jun 2003 22:28:29 -0400
Received: by localhost with Microsoft MAPI; Tue, 3 Jun 2003 22:28:28 -0400
Message-ID: <>
From: "Eric D. Williams" <>
To: 'Yakov Shafranovich' <>, Vernon Schryver <>, "" <>
Subject: RE: [Asrg] CRI Header
Organization: Information Brokers, Inc.
X-Mailer: Microsoft Internet E-mail/MAPI -
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <>, <>
List-Id: Anti-Spam Research Group - IRTF <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
List-Archive: <>
Date: Tue, 03 Jun 2003 22:23:17 -0400
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

On Tuesday, June 03, 2003 1:56 PM, Yakov Shafranovich 
[] wrote:
> >I thought you guys were clever to use MIME for more than one reason.
> >Pushing a new official RFC 2822 header (other than an ad hoc X-whatever)
> >through the IETF would take a year or more and you might fail.  That
> >you are sure challenge/response systems will be effective against spam
> >will be a weak response to Last Call criticisms.  However, I've the
> >impression that MIME headers don't have that bureuacratic problem to
> >the same degree.  That should be checked.
> According to section 2.1.1 of RFC 2048, there is plenty of bureaucratic
> problems involved. I am assuming that we would want to register this MIME
> type under the IETF tree, if so the following from RFC 2048 applies:
> "The IETF tree is intended for types of general interest to the Internet
> Community. Registration in the IETF tree requires approval by the IESG and
> publication of the media type registration as some form of RFC."
> The MIME type would have to go through the standards process anyway.
> Additionally, all MIME types of type "message" which I am assuming will be
> used for CRI, have been registered based on RFCs (take a look at

The rigor of the Last Call and criticisms of a Standards Track RFC should not 
IMHO be a limiting factor on the work of this group.  The point would be 
whether a MIME type would be an appropriate methodology for addressing the 
'spam' problem.  This is not an IETF working group (as many have said).

As a researchy group perhaps the focus would be better placed on how such a 
MIME type would work and/or the benefits and constraints of using either a MIME 
type or 2822 ad hoc private header field (X-).  How such a content type would 
work is also a valid research area in addition to what effects such a construct 
would have on the 'spam' problem.

IMHO I would not focus on what the IETF process is at this stage OR if it is a 
must to you, I would suggest including it as a constraint or assumption that is 
addressed by the documentation of proposed method.


Asrg mailing list