-----Original Message-----
From: owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
[mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com]On Behalf Of
william(at)elan.net
Sent: Monday, September 27, 2004 4:14 PM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: RE: [spf-discuss] Processed-By (or Transmitted-By) header
concept
On Mon, 27 Sep 2004, Scott Kitterman wrote:
The Processed-By proposal would seem to require that I trust the remote
processor (forwarder) and believe that it's characterization of
the previous
path of the message is correct. If I trust the forwarder not
to lie about
where it got the message, why can't I just whitelist an SPF
classic checking
forwarder that I trust and be done with it.
You misunderstand. Processed-By headers only record the information about
what happened during forwarding. One of the headers recorded is
"Envelope-Submitter". And as it is "Envelope", i.e. its record of RFC2821
it can not be used unless the same server also used SUBMITTER during
mail command.
If system does not support SUBMITTER, it can still enter Processed-By
header and one may assume that information that went into what I
currently
called "on-behalf-of" (name I don't particularly like and would like to
find shorter two-word combination) would have been the SUBMITTER address.
This is no more or less "trusting" then the Microsoft PRA concept of
adding Resent headers that you have to trust but that may well be a lie.
I think finding a way to build a 2821 based SUBMITTER that projects an
appropriate identity into 2822 (the opposite of the MS PRA proposal)
good way to aid whitelisting.
That is exactly what combination of draft-leibzon-responsible-submitter
and the new Processed-By headers would do.
An additional draft on how to match the data in SUBMITTER and other
RFC2821 headers to data found in Processed-By may also be needed to
aid systems that are verifiying email and identify false headers.
OK, so would another way to say this be that the Processed-By concept is not
meant to be useful for authorization or authentication, but to be a
(somewhat) human readable log of what happened for troublshooting or other
purposes and that the SUBMITTER identity is meant to be used for
authorization processing?
And yes, I very much like the idea of SUBMITTER going from 2821 into 2822
instead of the reverse.
Scott Kitterman