Subject: 6. Proposals - Signing Received paths (was Re: [Asrg] Forged Paths...)

From: Yakov Shafranovich <[email-masked]>
Date: Tue, 08 Jul 2003 23:28:49 -0400

At 07:14 PM 7/8/2003 -0600, Art Pollard wrote:

>One of the big issues when it comes to spam is tracing where the message 
>has originated from.  Of course, this is complicated when people forge 
>headers to try to obfuscate the origin of the e-mail.
>
>What I propose is this:
>
>During each jump on the path that the e-mail takes to arrive to the 
>sender, each interim mail server digitally signs the path.
>
>So, typically, the path goes like this:
>
><Server1>,<Server2>,<Server3>,etc.
>
>What I propose is:
>
><Server1/Signature1>, <Server2/ Signature2>, <Server3 / Signature3>, etc.
>
>The signature would use the servers public / private keys and would be 
>computed over the paths up to that point.  Thus, if you were server 3, you 
>would digitally sign the path for server1, Server2, Server3.
>
>Then if someone wants (or more specifically their software), they could 
>request the public keys of the servers along the transmission path and 
>ensure that the mail message actually took the path that the Path: header 
>claims it did.
>
>Yes, I am aware that one RFC says that headers aren't supposed to get 
>above 900 bytes or so in length.  I think that this will need to change 
>eventually anyway, we might as well start now.  In this way, we can ensure 
>that each message has an originated server that may be tracked down.  (Or 
>the message simply gets rejected.)
>
>Of course, this may be easily extended by adding a <User> to the path so 
>it may be tracked back to the originating server and user.
>
>I doubt that this would break many mail servers and even if it does, given 
>an adequate amount of advance notice, I doubt it would be a problem anyway.

What you are suggesting is that each "Received:" line in the message be 
signed. This may be done by either including the signature in the 
"Received:" header which would require changing RFC 2821, section 4.4 OR 
perhaps via an optional header.

The question is does it matter? In today's Internet structure it is rare to 
see messages being delivered through more than one system - most messages 
are delivered directly from the originating MTA to the receiving MTA. So 
anything with extra received lines would look suspicious. Additionally, the 
real originator's IP would be inside the headers anyway, so does 
obfuscation  make a difference? If we start tracing this message over all 
of the originating paths, then we will find the system that sent it anyway. 
Also, using C/R or callback mechanisms to request from the originating 
server whether this message was actually sent might make this irrelevant.

It sounds like a interesting idea but the details of signing, how the data 
is passed and whether the certificate is passed also, must be worked out.

Yakov

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg