On Wed, 6 Aug 1997, Adam Back wrote:

2) When the government or whoever wants to sue someone for spam they will have to prove who the spammer is. (Right?) So now they'll look at the From address at it will say remailer@foo.com. So they'll go have a chat to Fred Q Cypherpunk who operates foo, and he won't be able to cooperate because he doesn't keep logs. They won't be happy with Fred, and will pass this information along to him by stealing his equipment, prosecuting him for assisting in a felony crime (they'll make it a felony right?), lock him and throw away the key. But what about Freds constitutional protection of the speech forwarded by his remailer? (Judge + congress-critter: Constitution wassat?)

3) Repeat step 2 x 100 and "something will have to be done" about the remailers (if there are any left!) It really isn't that far fetched to have laws against remailers in the US. Not so long ago the guy from the two-man band Georgia EFF were telling us about how they fought some law which had already tried to do this in that state.

I suppose you could sue a local office or copier services place if I sent one "unsolicited commercial fax" using their equipment, but it would be impractical. Most of the spam I get has thousands of other recipients, and none of it has ever gone through a remailer, and always points to a "spam-friendly" ISP, or often already has their account cancelled by the time I report it. If we could get AGIS (the last of the large bandwidth suppliers) to pull the plug on the IEMMC sites - I already have many spams from their members violating their code - most spam would disappear. It also seems that AGIS is getting a bad reputation, but I don't know how many sites are leaving or joining, but if they don't have interesting content, and don't pull the plug on the IEMMC, adjustments to enough routing tables will accomplish the same thing. If we can stop the bulk spammers, things would quiet down. The problem is to stop the smokestack belching smoke without preventing me from using a torch in my back-yard at night. If remailers don't automatically do anonymous mailings to a 10,000 entry Bcc: list, they would only be able to spam a few hundred people at a time even using remailers. Generally that isn't enough to be worth the time since only a tiny fraction of a percentage will respond to generic requests. If you can only do 500, it would then pay to get a narrower list, or even personalize things, and I might actually read something that interests me. No one considers announcements for cryptographic technology products on this list as "SPAM". --- reply to tzeruch - at - ceddec - dot - com ---

Tim May <tcmay@got.net> writes:

[...] Nor are delivery services required to "know their customer" or to have ironclad proof of where a package originated. (Hell, even the U.S. Postal Service allows mail with no valid return address, and this was my experience in Europe as well.)

Because there is a from address people get picky that it ought to contain a valid return address. Many ISPs apparently have policies which state that you aren't allowed to do SMTP forgeries. Paper mail doesn't have this expectation. Pity the people who designed SMTP didn't leave this one out -- at this point it would be difficult to get a From field added. They could have followed the paper mail norm and left it to the user to include (or not) whatever contact info he wanted. Of course you can see the natural convenience of a From, or Replyto field, which is why it's there. Now that the from field is there, it'll be even harder to remove from implementations and protocols... basically impossible. Still the spam counter-measure which many people are starting to use of forging headers to avoid getting their email snarfed helps reduce the expectation that the From field will contain anything useful. However that isn't the only problem... the series of Received headers allow those with the know how to recognise and narrow down where forged mail came from. But usually only to a mail hub where it was injected at best, and then often only tentative with out collaboration with involved sites. Course Received: headers have their uses also, to debug sendmail configs, and work out where mail is going. Still would have been nice if the feature was only included in the SMTP delivery stuff when debugging mode was turned on.

The "From:" field in e-mail is not to be confused with the "originator" (whatever that may be).

Not even the U.S. courts are so dumb as to accept the claim that a package delivered by the U.S. Postal Servie or by UPS means that Joe Deliveryman is the "sender."

When this "From:" thing eventually gets to a court, I expect this distinction will be obvious to all.

Remailers are just middlemen in a delivery process.

I hope you're right. I still think laws against spam are the wrong approach, even if the courts declare remailers as delivery mechanisms only. "Write code, not Laws." (Btw who's quote is that? I like it and wanted to quote it in an article on Eternity.) Re spam problems and writing code and not laws, hashcash was my best attempt: http://www.dcs.ex.ac.uk/~aba/hashcash/ However coding is not the only problem, the other is getting people to use stuff. Advertising, subscribing to appropriate newsgroups, going to IETF meetings, deployment wins, but stuff dies due to little investment in advocacy. I haven't got the energy or resources to advertise the above. I reckon you could make nearly a full time job just reading and corresponding with people on enough news admin groups and mailing lists to get your message across to enough people to even begin to make an impact. I wrote the eternity service implementation 3 months ago, released source code: no interest. (Bar a few email messages saying "cool"). No demonstration system was the problem. Mike Duvos provided a demonstration system last week when I reposted the announce due to his discussing similar ideas, and poof: 4 eternity servers, wired article, another request to write an article for some magazine, offers to give talks at US universities. Wew. I also reckon, though obviously this is difficult to measure, that the few hours invested in producing the flashy title bar graphics with a more professional take off of the cypherpunks rose on field of entropy logo and pirate skull with crossed-swords added more to the appeal of the service than adding more features. My normal HTML coding style of drab grey with no graphics at all just doesn't look appealing. Adam -- Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/ print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<> )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`

nospam-seesignature@ceddec.com writes:

On Fri, 8 Aug 1997, Adam Back wrote:

...

[hashcash]

I think you never answered the fundamental question:

But to what advantage is it for *ME* to use hashcash?

Saying that it is neat, patriotic, pious, or any other adjective won't get my anonymous mail through any faster unless you can create a cartel of remailers that expidite hashcashed mail, or use some type of new remailer that others don't have and build hashcash into the distribution.

I wasn't talking about remailers above, but about end users. Hashcash allows the recipient to filter out email that hasn't got postage. As an interim upgrade path ISPs adopting it could be to bounce messages with out payments, and include a nonce, and instructions to resend including the nonce. Set up the filter so that the second post gets through. Spammers often don't have forged reply addresses for obvious reasons. (If spam crept up too badly in-spite of this you could at that point disable non-hash cash postage and give a URL for a java implementation where they just go to the web page and their browser will generate them some hash cash. Obviously this is inconvenient so I would be interested to see how the spammers adapted to just the nonce first. It's much easier to block spammers if they have to include replyable email addresses.) You would also have a no-postage list, for mailing lists etc. If we arrange so that spam won't get through without payment, it disincentivizes spammers. If some users go running around asking for `government to do something about spam', it could be suggested to them that it would be more effective to ask their ISP to install a hashcash patched sendmail. A remailer won't answer the bounce with nonce, so you automatically won't get remailer traffic without postage -- unless you put remailers on your no-postage list. If you're some media celebrity and you get too much email -- just turn up the squech, increase the postage required rate, and add people you do want to your no-postage list. You could auto-add anyone you ever manually replied to to the no-postage list even.

You still have the problem that a large organization can buy large computers just to do hashcash - look for networkable hashcash generators if it becomes popular.

I think the easiest initial way for the spammer to continue spamming you would be to target mailing lists, using forged addresses. Spam on mailing lists instead of mail is also a good thing for us, because we already have solutions for spam on mailing lists: decentralised 3rd party ratings -- NoCeMs can be applied to mailing lists. Allowing us to recommend good posts or mark what we consider spam. Individual users can decide which rating service to use. If you consider that hashcash can be setup to only charge postage for people you have never replied to in the past, this heavily discriminates against people who send large amounts of mail to random people. (Which is precisely the spammers mailing pattern!) Another solution with real ecash is to send ecash payment with mail and have filters that will similarly bounce messages if there is no ecash. The recipient by societal convention is expected not to cash the payment. People who cash your money you don't tend to send more email to. You could easily charge $1 and that would be a high price for the spammer -- it would be cheaper to snail mail you the spam. The above doesn't seem very friendly, or very in keeping with the spirit of free discourse. I think hashcash is nicer in this respect. I've taken the stuff on eternity to another message. Adam -- Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/ print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<> )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`

On Fri, Aug 08, 1997 at 10:45:29PM +0100, Adam Back wrote: [...]

I wasn't talking about remailers above, but about end users. Hashcash allows the recipient to filter out email that hasn't got postage.

Ie, hashcash is a fancy techie oriented self-labelling technique. :-) I didn't read the code, but it seems that the double spending protection is just local to the recipient (ie, there isn't a trusted central clearinghouse that checks against double spending on a global basis). Thus, a spammer could calculate postage for a message, then send 100000 copies. Hashcash would guarantee that each user only got one copy, but there are easier ways to do that. [If the checking was done at an ISP level, of course, only one message would get through. But that requires widespread deployment at the ISP level, not the individual user level, and checking at the ISP level requires that the ISP keep a database of users mail preferences.] But without a central clearinghouse hashcash seems useless to me as a means of combating spam. And of course, a central clearinghouse brings up a whole raft of other issues concerning trust and so on... [...]

You could auto-add anyone you ever manually replied to to the no-postage list even.

I would rather pursue a "tit-for-tat" strategy for email, but unfortunately tit-for-tat requires stable identities... -- Kent Crispin "No reason to get excited", kent@songbird.com the thief he kindly spoke... PGP fingerprint: B1 8B 72 ED 55 21 5E 44 61 F4 58 0F 72 10 65 55 http://songbird.com/kent/pgp_key.html

On Sat, Aug 09, 1997 at 10:14:28AM +0100, Adam Back wrote: [...]

You missed one aspect of the design. What the collision is calculated on is the recipients email address. If the collision is on someone elses email address, you reject it out of hand.

Ah -- of course. [...]

[btw: Kent: I tried out your .midi file under win95, all I had to do was double click on it. Almost melodic in an weird modern sort of way. Most cool anyway :-]

Of course, I am prejudiced, but I seriously think it qualifies as legitimate art. I spent a fair amount of time tweaking things so it would sound good to my ear. Years ago I did a lot of experimentation with algorithmically generated music -- it really grows on you. In "the old days" of DOS I had code that would drive a midi synth directly -- putting things to midi files makes things static, and not quite as interesting -- I liked having things that never sounded exactly the same thing twice. But I haven't had time to keep up with midi drivers in the Windows world. But this experiment sends my mind twitching off in other aesthetic directions -- your code was short enough so that it isn't boring -- if you had 20 minutes of "music" like that it would drive you nuts, and I would like to try some longer things -- a couple hundred lines of C code, for example. To make that work I was thinking of putting in a strong basic harmonic background, like a blues progression, and using the code text to drive a solo voice over it. Something like the "Triple-DES blues"... -- Kent Crispin "No reason to get excited", kent@songbird.com the thief he kindly spoke... PGP fingerprint: B1 8B 72 ED 55 21 5E 44 61 F4 58 0F 72 10 65 55 http://songbird.com/kent/pgp_key.html

On Mon, Aug 11, 1997 at 08:56:07AM +0100, Adam Back wrote:

[...]

Well here's DES... shouldn't be hard to construct a 3DES out of it

[...] I will try this.

How high can you crank up the bit rate? How about pgp.exe (270k or so from pgp263)?

Say 300k. I think the lower limit would be about twice the imput file size. Playing time: suppose each byte in the input was a single note, and, say 30 notes/sec (damn dense music). 10k seconds. About 3 hours long. Also, 30 notes/sec is too dense for any pitch-to-midi to work. Not really very practical :-)

Couldn't you sample voices, and use that through a vocoder? Say one line of the music was DES above which would come out as a real short burst... even pgp.exe at 270k wouldn't be that long at stereo CD quality sample, right?

Totally different technology than midi, of course. Certainly you could treat any data as a sample. The interesting question to me is whether anything aesthetically meaningfull could be generated -- pgp.exe as a sound sample would just be a short white noise-ish clip, probably -- "PGP - the noise". Once again, there seems to be no practical value to such an encoding, that I can think of at least, so aesthetics are the only reason to generate something. Midi gives you the opportunity of mirroring textual patterns in sound, and since text is meaningful, the game I am playing is to try to make a musical meaning out of it. It's kind of fun... -- Kent Crispin "No reason to get excited", kent@songbird.com the thief he kindly spoke... PGP fingerprint: B1 8B 72 ED 55 21 5E 44 61 F4 58 0F 72 10 65 55 http://songbird.com/kent/pgp_key.html