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

From: Danny Angus <[email-masked]>
Date: Tue, 28 Sep 2004 09:09:25 +0100

William,

The problem I see with this is that multiple hops cannot be used in
conjunction with New-xx and Original-xx headers.
What you'd have to do would be to use a single header which both identifies
the hop that changed the headers and records the change.

Lets assume that the regular headers are rewritten and therefore contain
the "new" values, so we only really need to preserve the history.
That can be accomodated in the "Processed by" by simply inserting the
original values for the fields logged as changed.

Processed-By: odin.ietf.org (ip=[132.151.1.176])
  on-behalf-of [email-masked]
  changed-fields List-ID=oldvaluee,Sender=oldvalue,CC=oldvalue,

Envelope-Recepient=oldvalue,Envelope-ReturnPath=oldvalue,Envelope-Submitter=oldvalue

  process-type maillist (list-id=<ietf.ietf.org>) ;

As for the name, call it like it is. If this is to address the issues of
automatic (c.f. by a users explicit action) re-insertion of messages into
the delivery system call it
"Reinserted-by"

But... also add a timestamp so we can accurately order these things

Reinserted-By: odin.ietf.org (ip=[132.151.1.176])
  on-behalf-of [email-masked]
  changed-fields List-ID=oldvaluee,Sender=oldvalue,CC=oldvalue,

Envelope-Recepient=oldvalue,Envelope-ReturnPath=oldvalue,Envelope-Submitter=oldvalue

  process-type maillist (list-id=<ietf.ietf.org>) ; Tue, 28 Sep 2004
00:43:21 -0700 (PDT)

At the end of the day though it still looks like a mechanism by which
someone could fabricate a whole imagined history for a message, rather than
anything upon which we could rely.

d.

---
Danny Angus
(apache james)

> Together with it introduced are
> Original-???? headers which are to be used to preserve original
> values of the headers that are being changed.

***************************************************************************
The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient (or responsible for delivery of the message to the intended recipient) please notify us immediately on 0141 306 2050 and delete the message from your computer. You may not copy or forward it or use or disclose its contents to any other person. As Internet communications are capable of data corruption Student Loans Company Limited does not accept any  responsibility for changes made to this message after it was sent. For this reason it may be inappropriate to rely on advice or opinions contained in an e-mail without obtaining written confirmation of it. Neither Student Loans Company Limited or the sender accepts any liability or responsibility for viruses as it is your responsibility to scan attachments (if any). Opinions and views expressed in this e-mail are those of the sender and may not reflect the opinions and views of The Student Loans Company Limi!
 ted.

This footnote also confirms that this email message has been swept for the presence of computer viruses.

**************************************************************************

---

From: Douglas Otis <[email-masked]>
Date: Tue, 28 Sep 2004 07:53:08 -0700

> anything upon which we could rely.

Rather than attempting to chain MAIL FROM to MAIL FROM  with a series of
new headers there is a much easier way to arrive at your goal. 
(Assuming the goal is to track the user.)  Although currently the HELO
domain is being ignored as it is seldom authenticated, it does establish
an identity which does relate to the author of the message.  The HELO
domain indicates their choice of provider.  You can use either the MAIL
FROM or the FROM mailbox domain to reference a simple name list that can
be obtained in a single lookup which includes the roots for all the
nominal providers for this mailbox domain.

_helo.my-mailbox-domain.com. PTR my-isp.com.
                                  PTR my-other-isp.com
                                  PTR coffee-shop.com
                                  PTR hotel.com
                                  PTR office.com
For more details see:
http://www.ietf.org/internet-drafts/draft-otis-marid-mpr-00.txt 
 
The information you need to establish this daisy chain already exist
within the current SMTP protocol.  It only requires that the HELO domain
authentication be repaired. (Thanks to Dave Crocker, this is being done
with CSV.)  And a simple name list as in the example.  Unlike SPF,
declaring this list "open-ended" will not invite spoofing.

I assure you this technique never requires a sequence of queries as is
needed for SPF.  This technique provides the SAME information that could
be obtained using either SPF or Sender-ID for that matter.  In fact, the
list could be designated to be valid for the PRA mailbox domain.  Rather
than using a generic label like _mpr or _helo as in the example, there
could be lists such as with labels using _mailfrom, _from, or _pra for
that matter.  If the goal is to decide if the message is being spoofed,
then this accomplish that goal in a much safer manner.

Using a script to provide a comprehensive address list for a vast array
of hosts will demand constant maintenance or excessive lookups.  The
alternative is to simply list the names of the domains being used.  Even
CSV just uses names and therefore does not require the address to be
defined.  (This is a function of the record.)  The need for a parser
also risks constraining the source port for the DNS query and then
walking through a sequence of domain name servers is absolutely risky.

Again, if you describe your goals and worry less about applying a series
of band-aids, the goal can be safely achieved. 

-Doug

---

From: [email-masked] (Justin Mason)
Date: Tue, 28 Sep 2004 12:12:37 -0700

> anything upon which we could rely.

I think that's unavoidable in a lot of cases -- the best approach to
deal with that is to either

  - (a) do not trust anything that wasn't added by a machine on
    your own network, or

  - (b) know where your "trust boundaries" lie, and stop looking
    once the message has gone one step beyond that boundary, since
    any other tracking info is possibly forged.

This is the approach we take in SpamAssassin when dealing with
Received headers.

- --j.

> The information in this e-mail is confidential and for use by the
> addressee(s) only. If you are not the intended recipient (or
> responsible for delivery of the message to the intended recipient)
> please notify us immediately on 0141 306 2050 and delete the message
> from your computer. You may not copy or forward it or use or disclose
> its contents to any other person. As Internet communications are
> capable of data corruption Student Loans Company Limited does not
> accept any  responsibility for changes made to this message after it
> was sent. For this reason it may be inappropriate to rely on advice
> or opinions contained in an e-mail without obtaining written
> confirmation of it. Neither Student Loans Company Limited or the
> sender accepts any liability or responsibility for viruses as it is
> your responsibility to scan attachments (if any). Opinions and views
> expressed in this e-mail are those of the sender and may not reflect
> the opinions and views of The Student Loans Company Limi!
>  ted.
>

---

From: Douglas Otis <[email-masked]>
Date: Tue, 28 Sep 2004 13:55:27 -0700

> This is the approach we take in SpamAssassin when dealing with

This is also a good reason to reconsider the use of an authenticated
HELO domain and Received headers.  This name never relies upon anything
beyond the adjacent agent outside the local domain.  It is dead simple
for a mailbox domain to reference a list of root names for all approved
mail transfer agents.  Use this information, obtained in one DNS query,
to detect spoofing.  No address entries are needed to support this
mechanism and open-ended lists are not a problem.

-Doug

---

From: "william(at)elan.net" <[email-masked]>
Date: Tue, 28 Sep 2004 16:41:02 -0700 (PDT)

> the hop that changed the headers and records the change.

I'll have recomendations how they can, basicly saying that Original-*
headers that follow Processed-By and that are specifically mentioned in
Processed-By changed list should be considered to be part of the same
trace data.
 
>   process-type maillist (list-id=<ietf.ietf.org>) ;

I partially agree with it, especially as it concerns envelope data.
I note that RFC2821 identities are in standard mailbox format and its
easier to add them as part of the header line, but RFC2822 headers
have more complex structure and its difficult to encapsulate them
as part of trace header, so I prefer to simly allow MTAs to copy them
as is into "Original-" header.

So my solution is thus that changes to envelope data would be reported
as part of the Processed-By header (just like it is done currently
in Received headers) but that Original-xxx headers stay for reporting
values that RFC2822 headers had before they were changed.

Youre suggestion about timestamp is also appropriate and I already thought
it might be good idea myself before too. So here is example of new format 
that I propose for this trace header:

Processed-By: odin.ietf.org (ip=[132.151.1.176])
   on-behalf-of [email-masked]
   original-envelope recepient=[email-masked],
    return-path=[email-masked], submitter=[email-masked]
   new-envelope recepient=[email-masked], 
     return-path=[email-masked], submitter=[email-masked]
   changed-headers To, List-ID, Sender, CC
   process-type maillist (list-id=<ietf.ietf.org>) ; 
    Tue, 28 Sep 2004 00:43:21 -0700 (PDT)
Original-To: [email-masked]
Original-Sender: [email-masked]

I'll note that NOT ALL headers that are listed in "changed-headers"
are present as separate Original-* headers. Those that are not present
are considered to have been added rather then changed, so of the above
the two headers that have been changed are "To" and "Sender" while
"CC" and "List-ID" have beed added by mail list but there were not
previously in the email message data. This brings the question if it is 
better to separate these into "changed-headers" and "added-headers"?

> the delivery system call it "Reinserted-by"

The header is intended for use by MTAs doing automated procesing 
during transmission of the message, not by processes done by MUA.
In fact the text might even state that if user-action forwarding
is done than it maybe more appropriate to use Resent- headers
instead of Procesed-By header. That is why my original name was
"Trasmitted-By" - it reflects that changes are being done during
transmission of the message, however the name does not well show
that header informs about changes in message parameters, so I think
I'm going to continue with "Processed-By" name.

> anything upon which we could rely.

That is obsolutely true and I'll have to mention this in the "Security 
Considerations" section. So this header is nothing more then new kind
trace header like Received that is intended to aid systems that are 
trying to see what happened to the message in transit and they are 
supposed to view this with the same level of believe as received headers.

However if ultimately we develop an automated email signature system
than it would be possible to provide by means of encryption algorithm
to confirm that headers were indeed added by whoever claimed it and
then its a matter if you trust that system to report what happened 
to email in truthfull way or not. 

On this note, in the next version of MTA Signatures proposal, I'll have a 
better way to sign trace headers (actually it'll look closer to Yahoo DK 
with header signature line that will reflect signing of multiple headers 
proceeding the line - but with actual encryption data being still in the 
separate PKCS7 MIME attachment).

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

---

From: "william(at)elan.net" <[email-masked]>
Date: Tue, 28 Sep 2004 16:45:07 -0700 (PDT)

And FYI - I really do appreciate all suggestions I received both public 
and private ones. They are all very helpfull and even if I do not respond
to you directly, I'm gratefull for you participation in development
of this idea.

William