Keith Moore wrote:
[quoting Nathaniel Borenstein]
The "Received" header is woefully inadequate for spam tracing
I'm not quite ready to abandon it, primarily for practical reasons:
+ it's already widely implemented
+ it's already used for spam tracking
Any alternative will require substantial time to pick up enough momentum
to be useful.
Granted, there are some issues that need to be resolved:
- the machine-readable parts should have reliable information
RFC 821 as amended by 1123 seems to permit this (relevant verbiage having
been copied, warts and all, into 2821), though not specified clearly
enough
to ensure interoperable machine-readable implementations.
- of course, some time will be required to migrate existing implementations,
however, I expect that to happen reasonably quickly, certainly more
quickly
than a ground-up replacement
If we really want to make mail traceable, we need to do a bit more
than fix Received. As I see it, we need:
[...]
But do we really want traceability? Or to put it another way, do we
really want to put hooks in the mail system that make mass
surveillance (by governments, or perhaps even by large companies or
unscrupulous ISPs) that much easier?
What I'm after is a means of automating tracing for abuse complaints.
I don't expect:
a) to be able to use Received field content on-the-fly to reject spam
b) to be able to personally identify the individual responsible -- I'll
leave that
to his ISP's abuse department
c) the legal system to be of any use whatsoever regarding spam; nothing
significant
has changed since Jonathan Swift wrote "Gulliver's Travels" (q.v.;
e.g. see
http://swift.thefreelibrary.com/Gullivers-Travels/4-5 and search for
"perplexed")
in 1726.
And no, I certainly don't want a Big Brother mechanism. I expect ISPs
to behave
responsibly and in the community interest (and for the most part, they
do -- they
aren't any happier about having their resources wasted by spammers than
anybody
else).
Here's a concrete example of a recent spam message's Received fields,
manually traced,
with comments interspersed. Given the appropriate information in
machine-readable
form, there's no reason why this couldn't be automated.
Received: from mr06.mrf.mail.rcn.net (207.172.4.25 [207.172.4.25])
by ms07.mrf.mail.rcn.net (Mirapoint Messaging Server MOS 3.2.2-GA
FastPath)
with ESMTP id CDL85988;
Mon, 12 Jan 2004 06:14:33 -0500 (EST)
That's my ISP's mail servers (I recognize both the domain name and IP
address).
Received: from mx03.mrf.mail.rcn.net (mx03.mrf.mail.rcn.net [207.172.4.52])
by mr06.mrf.mail.rcn.net (Mirapoint Messaging Server MOS 3.3.5-GR)
with ESMTP id BGS07944;
Mon, 12 Jan 2004 06:14:31 -0500 (EST)
Another of my ISP's mail servers; note that mr06.mrf.mail.rcn.net in the by
component matches the from component of the Received field which was added
after this one. Note also that the timestamps are close in time and
flowing in the
correct direction.
Received: from pool-207-68-110-60.alt.east.verizon.net ([207.68.110.60])
by mx03.mrf.mail.rcn.net with smtp (Exim 3.35 #4)
id 1Ag01f-0006Td-00; Mon, 12 Jan 2004 06:14:31 -0500
That records whence my ISP's MX receiver received the message; a Verizon
customer.
Had I only the IP address, a reverse lookup would have told me that.
N.B. the time stamp
remains consistent.
Received: from [132.214.45.221] by
pool-207-68-110-60.alt.east.verizon.net; Tue, 13 Jan 2004 07:15:55 +0600
That one's bogus; at the time of receipt, the timestamp was in the future.
The spam complaint went to abuse(_at_)verizon(_dot_)net(_dot_)
[BTW, w.r.t. other trace fields inserted by ISPs, you might well see
some in the header
of this message...]
#################################################################
#################################################################
#################################################################
#####
#####
#####
#################################################################
#################################################################
#################################################################