Subject: RE: [Asrg] CRI Header

From: "Eric D. Williams" <[email-masked]>
Date: Sat, 7 Jun 2003 23:11:01 -0400

On Thursday, June 05, 2003 10:57 AM, Yakov Shafranovich 
[SMTP:[email-masked]] wrote:
> At 11:15 PM 6/4/2003 -0400, Eric D. Williams wrote:
>
> >On Wednesday, June 04, 2003 3:54 PM, Eric Dean [SMTP:[email-masked]]
> >wrote:
> >8<...>8
> > > ok..optional headers or do we introduce a new one?  There isn't an RFC
> > > 2822
> > > registration process that I am aware of.
> >
> >IMHO the question at this stage is 'optional headers or the introduction
> >of an
> >new one?  Would a comparable RFC 2822 header field be as effective?'
> >[..]
>
> Both an "X-CRI" and "CRI" headers should be defined. Until the standard
> gets approved, the "X-" headers will be used, once the standard is approved
> then both the "X-CRI" and "CRI" headers are used. This is similar to the
> HTTP protocol where both "gzip" and "x-gzip" are used to indicate gzip
> encoding (RFC 2616, section 3.5).

I understand that, thanks.  But the issue I was trying to interpose is that 
perhaps the consideration of which would be more effective for the proposal is 
the type of question that should be asked at this state.

-e
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: "Eric Dean" <[email-masked]>
Date: Sun, 8 Jun 2003 10:47:00 -0400

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

> -----Original Message-----
> From: Eric D. Williams [mailto:[email-masked]]
> Sent: Saturday, June 07, 2003 11:11 PM
> To: 'Yakov Shafranovich'; 'Eric Dean'; [email-masked]
> Subject: RE: [Asrg] CRI Header
>
>

---

From: Yakov Shafranovich <[email-masked]>
Date: Sun, 08 Jun 2003 13:35:22 -0400

Now that the issue on the RFC 2822 headers is settled, I would like to 
bring up the issue of MIME and SMTP for CRI. Like I pointed out before, in 
my opinion the CRI protocol should utilize both RFC 2822 and MIME headers, 
with optional SMTP negotiation. In certain instances, like Vernon stated, 
MIME headers would have to be used when large amounts of data (larger than 
the 998 character limit of RFC 2822 headers) need to be transferred. 
Examples would be C/R systems transferring digital certificate chains and 
replying with a single challenge/response message for multiple recipients. 
Additionally, SMTP CRI via some ESMTP extension would be useful in certain 
cases.

Another very important point, is the need to define the CRI protocol as 
extensible. We need to provide space for implementors to add their own 
features such as hash cash, digital signatures, etc.

Yakov

---

From: [email-masked]
Date: Tue, 10 Jun 2003 22:50:39 -0400

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

  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.

  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)

  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.

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

  BTW, for those who despise b0rken mailing-list software, here is the
answer, via procmail.  Generate your own "Reply-To:" header...

:0 fhw
* ^X-BeenThere:.*asrg@ietf\.org
* !^Reply-To: asrg@ietf\.org
  | formail -i "Reply-To: [email-masked] (ASRG list)"

  ISP-wide implementations that send challenges via regular email
address some, but not all of the above issues.

-- 
Walter Dnes <[email-masked]>
Email users are divided into two classes;
1) Those who have effective spam-blocking
2) Those who wish they did
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Yakov Shafranovich <[email-masked]>
Date: Thu, 12 Jun 2003 14:32:47 -0400

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

>forged "From:" addresses don't mailbomb innocent 3rd parties if rejected

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.

>           b) luser administering it on his own MUA (Aunt Ethel or your

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.

>multiple accounts at different ISPs.

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

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

---

From: [email-masked]
Date: Fri, 13 Jun 2003 17:58:42 -0400

On Thu, Jun 12, 2003 at 02:32:47PM -0400, Yakov Shafranovich wrote

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

  Given those powers, I'd subpeona the ISP's logs instead, or at least a
subset generated by grepping for the suspect's email address as the
destination.  Spam Rule #3, or some corollary thereof, applies to
"military intelligence".  They're stupid and incompetent, and think that
the bad guys are too.  Assuming that...
  a) I was a bad guy, and
  b) I'd do something as silly as sending instructions via email
  I could...
  - subscribe to this list
  - whitelist envelope-sender "[email-masked]"
  - tell my co-conspirator to forge "[email-masked]" as the
    envelope-sender when emailing me

  My whitelist would look very innocent, and "military intelligence"
would still have to take a good look at the ISP's logs to figure our
what was going on.  Even simpler, we'd set up as spammers, and *NOT* use
tight whitelists.  Specially coded porno spams that open a dozen browser
windows would also open one which had a porno gif with steganographic
embedded encoding of instructions.

---

From: Yakov Shafranovich <[email-masked]>
Date: Sat, 14 Jun 2003 23:02:12 -0400

At 05:58 PM 6/13/2003 -0400, [email-masked] wrote:

>destination.
[..]

ISP logs are not around for very long, whitelists for C/R systems are. 
Plus, ISP logs might be congregated for thousands and thousands of 
customers, while email preferences are unique per user and more easily 
identifiable.