[Top] [All Lists]

Re: "Header Reordering", yet again

2005-05-31 11:37:45

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

Or just use DomainKeys to sign the Received-SPF header field ;)

You should be more serious, this can actually be quite good if properly

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: ; seq=101; time="Thu, 26 May 2005 05:20:05-0700"
META-Signature: ver=1.0 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 ;
      auth=txt u="" fp="fp1="
EDigest: v=1.0 a=sha1 c=nofws e=7bit t=1094844765.334354
Received: (from majordom(_at_)localhost)
    by (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: <>
Redirected: by (ip=[])
            on-behalf-of list(_at_)example(_dot_)com process-type mail-list
            original-envelope recipient=list(_at_)example(_dot_)com
            new-envelope recipient=touser(_at_)example(_dot_)com
            changed-header Reply-To, List-ID, Subject ;
            Thu, 26 May 2005 05:20:04 -0700
Received: from ( []
    by (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: ; 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
<Prev in Thread] Current Thread [Next in Thread>