Steve Atkins,
I'm not Steve, but what the heck.
and discuss the concepts that I broached. A technical topic not mentioned in
that article specifically is the use of the sender's email address, recipient's
email address, and the date and time of the message event to seed or salt a
random number generator.
It's clever, but since the fundamental problem with proof-of-work is
that the bad guys can do more work than the good guys, the details of
the work aren't particularly interesting.
reduce spam (2). It could be that your conclusion addresses one criterion (1),
while other criteria (2) and (3) could be achieved by increasing the
computational costs of sending and receiving emails.
No, because the bad guys still have more computational power than the
good guys. You could get rid of spam, but only at the cost of getting
rid of all of the rest of e-mail, too.
Effective anti-spam techniques have to be things that it's easier for
good guys to do than for bad guys to do. This turns out to be hard.
It also turns out to be subtle. For example, both good and bad
senders can apply DKIM signatures to their mail, so signing per se is
not an anti-spam technique. What makes them useful is that the
signing identifiers can be keys into reputation systems that are
designed to favor good signers.
Also, what might you think about discussions about versioning and advancing
email protocols, modernizing email-related computer networking protocols?
SMTP has had an extension mechanism since RFC 1869 in 1995. There
have been quite a lot of extensions proposed, some of which, such as
pipelining and 8bitmime, are now universally adopted. Early
definitions of SMTP had commands such as SOML and TURN that were found
either not to be useful, or to have serious security problems, so
they've been deprecated and eventually deleted. It's not exactly
versioning, but the protocol has evolved somewhat.
There have been a lot of proposals to "replace SMTP", but none have
come anywhere near close to demonstrating sufficient utility to
motivate people to bear the enormous switching costs from the existing
deployed system.
R's,
John
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg