On Tue, 31 May 2005, Arnt Gulbrandsen wrote:
Valdis Kltnieks writes:
If you're planning to go down this bad-idea path, you *really* need to
specify
that the two headers are linked with some glob that has msgid-like
uniqueness
properties....
Or just use DomainKeys to sign the Received-SPF header field ;)
You should be more serious, this can actually be quite good if properly
developed.
--------
Now, since this is IETF list IPR declaration/info is appropriate as I have
recently filed patent application in this area that would in part cover
domainkeys-like MTA cryptographic signature system signing message
data with information about previous hop (i.e. its address, etc) and/or
information about how that hop was authorized. The recipient (MUA or MDA)
would be expected to authorize the signature using signing system hostname
as "sender" and if it recognized that hostname as being "trusted forwarder"
(or authorization can be based on cryptographically verifiable relationship
with recipient which establishes this trust), it can then use signed data
about source system entered by the forwarder (either info about authorization
results or it can do its own SPF or like path authorization based on
original connection source and identity data that forwarder saw).
Note: Domainkeys itself can not be used because it can only add signature
if signing system is working on behalf of the sender and then dk signing
system would be expected to have access to sender's private key. Where as
forwarding systems are not working on behalf of the sender, but on behalf
of the recipient so different type of cryptographic relationship can be
used and different type of signature authorization. But META Signatures
can be used here if authorization is based on signing system name (entered
as sender name, this is more clear in upcoming 0.21 spec which actually
allows to specify type authorization sender relationship).
--------
As for identification trace data entered by one system and making sure
trace data is properly ordered and recognized, I've been working on this
concept as well and decided to just add starting and ending trace header
fields to identify trace block added by one system. Yes, I know new trace
fields can not be relied to not have been reordered and you'll see me
deal with that in future draft. Below is an example of how this trace data
block might look like (and sorry about long example and fields with syntax
from documents not yet released):
Trace-End: ml.example.com ; seq=101; time="Thu, 26 May 2005 05:20:05-0700"
META-Signature: ver=1.0 i=ml.example.com t=1094844754.338503 x=432000 ;
cont=hlist h=Received,Redirected,Trace-*,Saved-*,EDigest,Message-ID,
From,To,Date,Content-* ;
sig=rsa-sha1 d="grUU7EOwzCbuoejh39KE+epT3zGdmAP693IOGujxSBb+4qtI1..."
e="Iw==" m="zCnd+ByA23/7WMiIwaIZ7Ez3DplzVMdRKP138IXLOvBV..." ;
id=host s=ml.example.com ;
auth=txt u="dns:ml.example.com?type=SPF" fp="fp1="
EDigest: v=1.0 a=sha1 c=nofws e=7bit i=ml.example.com t=1094844765.334354
d="51f0483a89e441e2fc45a12a4303ca217f34617e="
Received: (from majordom(_at_)localhost)
by ml.example.com (8.12.11/8.12.9/Submit) id abcderfg;
Thu, 26 May 2005 05:20:04 -0700
Saved-Subject: "[list] Test"
Saved-Reply-To: list(_at_)example(_dot_)com
Saved-List-ID: <list.example.com>
Redirected: by ml.example.com (ip=[10.5.0.1])
on-behalf-of list(_at_)example(_dot_)com process-type mail-list
original-envelope recipient=list(_at_)example(_dot_)com
return-path=fromuser(_at_)example(_dot_)com
new-envelope recipient=touser(_at_)example(_dot_)com
return-path=list(_at_)example(_dot_)com
changed-header Reply-To, List-ID, Subject ;
Thu, 26 May 2005 05:20:04 -0700
Received: from origin.example.com (origin.example.com [10.0.0.1]
by ml.example.com (8.12.11/8.12.9) with SMTP id abcdefg
for <list(_at_)example(_dot_)com>; Thu, 26 May 2005 05:20:03 -0700
Trace-Start: ml.example.com ; seq=101; time="Thu, 26 May 2005 05:20:03-0700"
P.S. I'm also going to take into account (in the draft) that most end-users
don't want to see that much trace data (or in fact any trace data and
certainly don't want to have to download 5k message when it really has
only 10 words in the body) and its only of interest during mail processing
or debugging errors or abuse in most cases.
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net