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.
that's true of any new information that might be provided regardless of
whether it uses a new header field or if the new information somehow
gets stuffed into the received field. the point is, the existing
information is unreliable and inadequate.
What I'm after is a means of automating tracing for abuse complaints.
me too. but I don't see how we can do that without providing
non-repudiation. otherwise it becomes easy to DoS somebody by forging
mail as if it were from them and generating lots of complaints about
it.
nor do I think it's sufficient to get ISPs to terminate spammers. what
we need is a way to find out if a message is spam (or if the sender is
a spammer) after the message is sent, but before it is delivered or
read.
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).
it's pretty hard to behave in the community interest when Big Brother
is twisting your arm.