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
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg