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`