On Tue, 2004-09-28 at 01:09, Danny Angus wrote:
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 ietf(_at_)megatron(_dot_)ietf(_dot_)org
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 ietf(_at_)megatron(_dot_)ietf(_dot_)org
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.
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