Subject: Processed-By (or Transmitted-By) header concept

From: "william(at)elan.net" <[email-masked]>
Date: Mon, 27 Sep 2004 12:06:33 -0700 (PDT)

I also started working on draft that tries to deal with a problem that
when email message passes through forwarders, email lists and other
similar systems those systems make changes to important email headers
and to envelope and its difficult to tell at later time what changes
they have made (or if these changes happened at all) and who is to be 
considered responsible for making these changes.

The concept introduces new header "Processed-By" (alternative name
"Transmitted-By", let me know which name you like better) and this
header is to be used to list name of the system making changes to
email message, email address of responsible party and list of
headers that are being changed. Together with it introduced are
Original-???? headers which are to be used to preserve original
values of the headers that are being changed. For RFC2821 envelope
parameters that are changed Original-Envelope-??? headers can be used.
Additionally "New-????" headers maybe used to list how these headers
were changed (this is intended primarily for RFC2821 envelope data).

It is intended that Processed-By header would be added by any
system that is changing destination of email message or its source.

Below I'm going to give some example of how these header might
be used by forwarders and by email lists, etc:

----------------------------------------------------------------------
1. Mail List (changes to envelope and to header to and sender):

Processed-By: odin.ietf.org (ip=[132.151.1.176])
  on-behalf-of [email-masked]
  changes-to List-ID,Sender,CC,
    Envelope-Recepient,Envelope-ReturnPath,Envelope-Submitter
  process-type maillist (list-id=<ietf.ietf.org>) ; 
New-Envelope-Recepient: [email-masked]
New-Envelope-ReturnPath: [email-masked]
New-Envelope-Submitter: [email-masked]
Original-Envelope-Recepient: [email-masked]
Original-Envelope-ReturnPath: [email-masked]
Original-Envelope-Submitter: [email-masked]
Original-To: [email-masked]
Original-Sender: [email-masked]

2. Forwarding system that does not change RFC2821 Mail From

Processed-By: mail.forwader-example.com (ip=[10.0.0.10])
  on-behalf-of [email-masked]
  changes-to Envelope-Recepient,Envelope-Submitter
  process-type forwarding
New-Envelope-Recepient: [email-masked]
New-Envelope-Submitter: [email-masked]
Original-Envelope-Recepient: [email-masked]
Original-Envelope-Submitter: [email-masked]

3. An outgoing SMTP proxy system that sits in the hotel and is to
   be used by all guests (sets Sender header and RFC2821 submitter)

Processed-By: proxy.hotel-example.com (ip=[10.0.0.10])
  on-behalf-of [email-masked]
  changes-to Sender,Envelope-Submitter
  process-type smtp-proxy
New-Envelope-Submitter: [email-masked]
Original-Envelope-Submitter: [email-masked]
Original-Sender: [email-masked]
----------------------------------------------------------------------

Please let me know what you think of this concept and if you think it
would be usefull and send me your comments and suggestions. And I do
expect to have draft available describing this within one or two weeks.

---
William Leibzon, Elan Networks:
 mailto: [email-masked]
Anti-Spam Research Worksite:
 http://www.elan.net/~william/asrg/

---

From: Douglas Otis <[email-masked]>
Date: Mon, 27 Sep 2004 12:39:32 -0700

> be used by forwarders and by email lists, etc:

Assuming any identity added will need to undergo authentication, how
would this identity be substantially different than that already
possible employing the EHLO domain?  This EHLO information is already
present within the initial exchange and recorded within the messages
headers.  Once authenticated, this EHLO name allows safe mail channel
assertions without the need to obtain an extensive address list.

-Doug

---

From: "william(at)elan.net" <[email-masked]>
Date: Mon, 27 Sep 2004 12:57:14 -0700 (PDT)

> assertions without the need to obtain an extensive address list.

Processed-By and Original- and New- are not identity headers.
They are all trace headers (like Received and Return-Path) intended
to be used by email agents that have made changes to either destination
or source (this being either the envelope parameters and rfc2822 email
address headers) of email transmission and would like a standard way to 
record this information in email message

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Douglas Otis <[email-masked]>
Date: Mon, 27 Sep 2004 13:30:15 -0700

> record this information in email message

Should the EHLO domain be authenticated, then whether a change has been
made to any headers or not still allows the message source to be
traced.  The EHLO domain can be selectively presented based upon a
desire to reference a particular domain.  The authentication of the EHLO
domain also allows the mailbox domain a simply reference to a name list
as a means to indicate the nominal mail channel without risk of this
information being exploited.  Such an exploit is possible with SPF or
Sender-ID, especially where the lists are left open and yet used within
a gate-keeper function.

It would make it easier if you could describe the problem being solved.

-Doug