mta-hashcash

mta-hashcash@lists.lysator.liu.se

244 discussions

Reference list
by nisse＠lysator.liu.se 05 Oct '04

05 Oct '04

For convenience, I've put together an html-version of Linus' reference list, as well as links to our files etc, at http://www.lysator.liu.se/~nisse/misc/mta-hashcash.html The files are also in the doc-directory in the cvs, feel free to add more references, or comment on the scope and relevance of the documents. Updating the files on the web requires a manual cvs update && make install-www WWWDIR=webdir on the right machine, so prod me whenever the www version seem out of sync. Regards, /Niels

1 0

Re: Test-implementation
by nisse＠lysator.liu.se 04 Oct '04

04 Oct '04

Linus Nordberg <linus(a)nordberg.se> writes: > nisse(a)lysator.liu.se (Niels Möller) wrote > 28 Sep 2004 09:16:35 +0200: > > | resource bör nog innehålla avsändare och mottagare (från > | smtp-kuvertet) och slumpmässigt salt (som bestäms av servern). > > Behöver vi plocka isär resource igen, tro? I sådana fall behöver vi en > separator mellan komponenterna. Inte ':'. Some answers to related questions: * The client must check that the resource string is constructed according to the rules, in order to avoid interleaving attacks. * I think the most robust way to achieve that is to let the client construct the resource string independently. The server only sends the salt in the challenge message. * I think it's good cryptographic practice to have the function that constructs the resource string from its inputs be collision free. I.e. there should not be two sets of input that results in the same resource string. The simplest ways to do that is to either use unique separator (if a suitable character exists), or add explicit length prefixes to each component. > | Datumet tror jag inte spelar så stor roll för oss. Men ska det > | verkligen bara vara två siffror för årtalet? > > Det är tydligen default. Man kan visst välja mellan 6, 10 och 12 med > `-z'. What does the ten-chracter format look like? 6-character dates is just too stupid for this millennium. > Skall epost-listan hållas på engelska tycker ni? English makes some sense, even if at the moment you and I are the only two subscribers. One other comment: I noticed that you refer to RFC 821 in the comments in your code. You should also look at the updated version, RFC 2821. /Niels

2 5

Re: Avskräckt?
by nisse＠lysator.liu.se 04 Oct '04

04 Oct '04

Linus Nordberg <linus(a)nordberg.se> writes: > http://www.cl.cam.ac.uk/users/rnc1/proofwork.pdf Now I've read that article. I didn't really try follow all the juggling and hand-waving with numbers. As I understand the conclusions, these are the important points as they apply to us: 1. We must be prepared to use challenges that take several minutes to solve. 2. To make things work for legitimate email, one must use a some "hybrid system" where hash-cash is used only occasionally for legitimate email. 3. The effectiveness depends on many hard-to-estimate factors, such as to number and cpu power of machines "0wned" by spammers. As for 2., that's exactly what we're doing. For 1., it seems we will make SMTP transactions take considerably longer time, and that "smarthost" MTA:s will easily get into trouble if for some reason the authentication mechanism doesn't work. Regards, /Niels

1 0

Sharing databases
by Linus Nordberg 30 Sep '04

30 Sep '04

Earlier, when thinking about aliases, we discussed the risk of having to come up with some mechanism for sharing key/correspondent databases between MTA's. There's another reason to discuss that, namely sites that use separate MTA's for sending and receiving and/or have more than one sending/receiving MTA. Large sites probably have lots of both. Smaller sites might have a setup with one host in some DMZ or similar, receiving all mail and then forwarding it to some internal host that's not reachable from the Internet. Outbound mail might take another route. As long as all the MTA's are operated by a single administrative entity, this might have some solution outside the scope of this work, perhaps using a central SQL server or similar but I'm not sure. It would of course be nice if we could present a simple and robust mechanism for database synchronization.

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

mta-hashcash