Re: [Asrg] CRI Header

Vernon Schryver <> Tue, 03 June 2003 18:17 UTC

Received: from ( [] (may be forged)) by (8.9.1a/8.9.1a) with ESMTP id OAA17885 for <>; Tue, 3 Jun 2003 14:17:10 -0400 (EDT)
Received: (from mailnull@localhost) by (8.11.6/8.11.6) id h53IGjo11656 for; Tue, 3 Jun 2003 14:16:45 -0400
Received: from ( []) by (8.11.6/8.11.6) with ESMTP id h53IGiB11653 for <>; Tue, 3 Jun 2003 14:16:44 -0400
Received: from ietf-mx ( []) by (8.9.1a/8.9.1a) with ESMTP id OAA17858; Tue, 3 Jun 2003 14:16:39 -0400 (EDT)
Received: from ietf-mx ([]) by ietf-mx with esmtp (Exim 4.12) id 19NGJA-0001Np-00; Tue, 03 Jun 2003 14:14:52 -0400
Received: from ([] by ietf-mx with esmtp (Exim 4.12) id 19NGJ9-0001Nm-00; Tue, 03 Jun 2003 14:14:51 -0400
Received: from (localhost.localdomain []) by (8.11.6/8.11.6) with ESMTP id h53IF8B11327; Tue, 3 Jun 2003 14:15:08 -0400
Received: from ( []) by (8.11.6/8.11.6) with ESMTP id h53ID8B11072 for <>; Tue, 3 Jun 2003 14:13:08 -0400
Received: from ietf-mx ( []) by (8.9.1a/8.9.1a) with ESMTP id OAA17623 for <>; Tue, 3 Jun 2003 14:13:03 -0400 (EDT)
Received: from ietf-mx ([]) by ietf-mx with esmtp (Exim 4.12) id 19NGFf-0001K5-00 for; Tue, 03 Jun 2003 14:11:15 -0400
Received: from ([]) by ietf-mx with esmtp (Exim 4.12) id 19NGFc-0001K2-00 for; Tue, 03 Jun 2003 14:11:14 -0400
Received: (from vjs@localhost) by (8.12.10.Beta0/8.12.10.Beta0) id h53ICq9C022852 for env-from <vjs>; Tue, 3 Jun 2003 12:12:52 -0600 (MDT)
From: Vernon Schryver <>
Message-Id: <>
Subject: Re: [Asrg] CRI Header
References: <>
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 12:12:52 -0600

> From: Yakov Shafranovich <>

> ...
> >If the goal is to get a CRI protocol defined and deployed to stop some
> >spam, why do you care about the fact that private headers (presumably
> >X-whatever) cannot become a standard?
> Inter-operability is a key, if X- headers are used (or MIME "x." type) then 
> nothing stops someone from making their own ones. The whole point of such 
> protocol is that it would be a standard that cannot be changes at the whims 
> of some vendor.

No, that is not the point of such a protocol, because the IETF does
not have an army.  The whims of vendors are not prevented by words in
documents labelled "RFC." The only people who really pay attention to
RFCs are programmers trying make things compatible and users, often
out of a misplaced religious reverence.  There are no "netcops" who
will disconnect non-conformant systems.  There have been and always
will be many cases where vendors have blandly ignored the clear words
in standards track RFCs.

More important, any vendor that wants to build a protocol with some
(other) X-header is always absolutely free to do so, no matter what
other protocols have been designed or are in use.  That is by design
and intent.  A stanards track challenge/response RFC or official SMTP
header would have no effect on anyone who doesn't want to play your
game by your rules.

The only effective purpose of an RFC is to document things so that
people who do want to play by other people's rules can learn what
those rules are.

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

That is mistaken.  IESG approval and writing an Informational or
Experimental RFC is very quick and easy compared to getting consenus
in the appropriate WG for an official and so Standards Track SMTP

Vernon Schryver
Asrg mailing list