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

On Mon, 2004-09-27 at 12:06, william(at)elan.net wrote:
> 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 protected]
>   changes-to List-ID,Sender,CC,
>     Envelope-Recepient,Envelope-ReturnPath,Envelope-Submitter
>   process-type maillist (list-id=<ietf.ietf.org>) ; 
> New-Envelope-Recepient: [email protected]
> New-Envelope-ReturnPath: [email protected]
> New-Envelope-Submitter: [email protected]
> Original-Envelope-Recepient: [email protected]
> Original-Envelope-ReturnPath: [email protected]
> Original-Envelope-Submitter: [email protected]
> Original-To: [email protected]
> Original-Sender: [email protected]
> 
> 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 protected]
>   changes-to Envelope-Recepient,Envelope-Submitter
>   process-type forwarding
> New-Envelope-Recepient: [email protected]
> New-Envelope-Submitter: [email protected]
> Original-Envelope-Recepient: [email protected]
> Original-Envelope-Submitter: [email protected]
> 
> 
> 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 protected]
>   changes-to Sender,Envelope-Submitter
>   process-type smtp-proxy
> New-Envelope-Submitter: [email protected]
> Original-Envelope-Submitter: [email protected]
> Original-Sender: [email protected]
> ----------------------------------------------------------------------
> 
> 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.

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