Re: [Asrg] CRI Header

Yakov Shafranovich <> Fri, 13 June 2003 10:33 UTC

Received: from ( [] (may be forged)) by (8.9.1a/8.9.1a) with ESMTP id GAA27645 for <>; Fri, 13 Jun 2003 06:33:53 -0400 (EDT)
Received: (from mailnull@localhost) by (8.11.6/8.11.6) id h5DAXQs28590 for; Fri, 13 Jun 2003 06:33:26 -0400
Received: from ( []) by (8.11.6/8.11.6) with ESMTP id h5DAXQm28587 for <>; Fri, 13 Jun 2003 06:33:26 -0400
Received: from ietf-mx ( []) by (8.9.1a/8.9.1a) with ESMTP id GAA27633; Fri, 13 Jun 2003 06:33:22 -0400 (EDT)
Received: from ietf-mx ([]) by ietf-mx with esmtp (Exim 4.12) id 19Qlpz-0003Um-00; Fri, 13 Jun 2003 06:31:15 -0400
Received: from ([] by ietf-mx with esmtp (Exim 4.12) id 19Qlpz-0003Uj-00; Fri, 13 Jun 2003 06:31:15 -0400
Received: from (localhost.localdomain []) by (8.11.6/8.11.6) with ESMTP id h5CIY1a14811; Thu, 12 Jun 2003 14:34:01 -0400
Received: from ( []) by (8.11.6/8.11.6) with ESMTP id h5CIXZm14761 for <>; Thu, 12 Jun 2003 14:33:35 -0400
Received: from ietf-mx ( []) by (8.9.1a/8.9.1a) with ESMTP id OAA22138 for <>; Thu, 12 Jun 2003 14:33:32 -0400 (EDT)
Received: from ietf-mx ([]) by ietf-mx with esmtp (Exim 4.12) id 19QWr7-00057l-00 for; Thu, 12 Jun 2003 14:31:25 -0400
Received: from ([] helo= ident=trilluser) by ietf-mx with smtp (Exim 4.12) id 19QWr4-00057W-00 for; Thu, 12 Jun 2003 14:31:23 -0400
Message-Id: <>
X-Mailer: QUALCOMM Windows Eudora Version
To:, ASRG list <>
From: Yakov Shafranovich <>
Subject: Re: [Asrg] CRI Header
In-Reply-To: <20030611025039.GA1809@m433>
References: <> <> <>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-MimeHeaders-Plugin-Info: v2.03.00
X-GCMulti: 1
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: Thu, 12 Jun 2003 14:32:47 -0400

At 10:50 PM 6/10/2003 -0400, wrote:

>On Sun, Jun 08, 2003 at 10:47:00AM -0400, Eric Dean wrote
> > I'm pretty sure that it's clear we should move forward with proposing
> > a new RFC2822 header.  If a BOF wants to throw an X in front of
> > it, then so be it.  I'll proceed br producing a draft with real
> > 2822-type headers.
> >
> > However, if someone out there is interested, we could interoperate
> > in the meantime using X or optional headers as well as with proposed
> > 2822 headers
>   Has any consideration been given to doing this at the SMTP stage
>rather than as part of DATA: ?  E.g. an EHLO which tries to negotiate a
>set of features, including CHRE:.  If the destination MTA says "Yes, I
>do CHRE:", then do a "CHRE:" step just after the "RCPT:" step.
>Advantages to this include...

We had been discussing this, especially considering that TitanKey's system 
is starting to move in that direction. We want to define the headers 
approach first, followed by MIME headers and ESMTP. We had also been 
considering using the ESMTP extension used for DSNs (RFCs 3461-3464) and 
the Message Tracking Protocol that is being developed by an IETF WG.

The consensus seems to be that SMTP approach is not right for everyone, the 
basic approach is using headers and MIME, with SMTP as an option for those 
who want it.

>   1) Spam runs from compromised home machines (Jeem.pv and Guzu) with
>forged "From:" addresses don't mailbomb innocent 3rd parties if rejected
>at SMTP time.

That was the advantage the Peter from TitanKey pointed out. His current 
system rejects email at SMTP level before the DATA command, and then sends 
a challenge.

>   2) Yes, I realize that the ISP's MTA will have to keep state
>information regarding the luser's preferences.  However, it comes down
>to either a) ISP's server doing it (maybe luser enters pre-emptive
>              whitelist/blocklist via web interface), or
>           b) luser administering it on his own MUA (Aunt Ethel or your
>              parents, yeah sure)

Privacy issues are a big concern here. Keep in mind that in the USA, this 
information can be subpoened by many parties ranging from the RIAA seeking 
copyright pirates to the FBI via the FBIS. Some approaches here such as 
using checksums, one way functions, cryptography, etc. are needed.

>   3) Clients can change MUA's, restore backed-up drives, format and
>re-install, access email via web interface or laptop or handheld, etc,
>etc, without worrying about replicating/propagating a small distributed
>database over several client MUA's and devices.  An XML structure to
>download and upload settings would also be nice for synchronizing
>multiple accounts at different ISPs.

We cannot mandate the changes to the whole world. As I mentioned, SMTP 
approach would be optional.

>   4) This would require changes in MTA rather than MUA.  The top 10 or
>twenty ISP's on the planet probably have 100,000,000 customers. Questions
>      a) is it going to be easier to implement changes at a couple of
>         dozen locations (plus multiple redundant MTAs) or a hundred
>         million locations (multiplied by the number of devices/MUA's the
>         clients use to access their email) ?
>      b) as per 2-b) do you expect Aunt Ethel to be competent to download
>         and install updated MUA's ?  Hint, consider how many people use
>         the default browser/mailer/newsreader that came with their OS.
>   5) Doing C/R via embedded headers means having to accept the entire
>email, because headers are part of DATA:.  This uses additional
>bandwidth, even if the destination MTA issues a 550.
>   6) Which is going to to impose more load on an MTA
>      a) handling an extra stage in the SMTP negotiation
>      b) accepting the entire email and parsing the entire body looking
>         for C/R headers
>   7) What about mailing lists (like this one for instance) that use
>b0rken 2-bit defaults where hitting "r" to reply sends a reply not to
>the list but to the individual sender ?  How difficult is it to insert a
>"Reply-To:" header?  How are MUAs going to handle Envelope-From.  Don't
>talk to me about "Return-Path:".  Many ISPs don't generate this on
>incoming email, many MUAs don't use it, and your Aunt Ethel doesn't know
>what it is, let alone the difference between "MAIL FROM:" and "From:".

All these issues are good points, thats why we are looking at an optional 
SMTP protocol. 

Asrg mailing list