On 10/07/2010 04:16 PM, Sven Olaf Kamphuis wrote:
you just give contacts for the passwords with which you have received a new one.
Hi Sven/others,
This very much sounds like TMDA:
http://tmda.net/ http://en.wikipedia.org/wiki/Tagged_Message_Delivery_Agent
Where by each person that needs to contact you, you give a unique e-mail address.
So you give out key1@domain.tld to user1 and key2@domain.tld to user2.
That's a good start, but for general use, if I'm handing out an address like "sven@jgreco.net" to Sven, and "leen@jgreco.net" to Leen, the real problem here is predictability. If Sven is a bad guy, he can cause trouble by guessing that I'd use "leen@jgreco.net" for Leen and proceed to pass that address out to spammers, making Leen look like a bad guy. That particular problem is reduced by generating random tokens for the LHS, however, doing so introduces new problems, such as the fact that "23ycs7ia877oij@jgreco.net" is no longer obviously associated with Sven. I've been very successfully using a much better tagging system here. Take a user-specified identifier, such as, say, "sven". You run this through a one-way crypto function, such as MD5: md5=`echo "${1}/SomeMagicSecret" | md5` f8=`echo "${md5}" | sed "s:^\(........\).*:\1:"` echo "${1}@${f8}.demo.jgreco.net" This results in something like nanog@e6ecd2ea.demo.jgreco.net Now this has a bunch of interesting properties. 1) You make *.demo.jgreco.net a DNS wildcard zone that is rewritten to your actual mailbox address. If and when a problematic address is issued, you can add at the DNS level an MX (or whatever nasty you prefer) for the particular domain name that's troubling you; for example, set e6ecd2ea.demo.jgreco.net to NS from 127.0.0.1. Never even touches the mail server. Of course MTA or procmail deny works too. 2) By using a separate zone, it makes it trivial to configure your mail system so that these addresses blow completely by any normal spam filtering; the problem of false positives for things like transactional e-mail that spam filters often find "spammy" vanishes completely. 3) You need not keep a database of valid tokens; you can simply re-validate the LHS in Procmail. This means that you can do things like write a mobile app or web app that doesn't have to have access to your mail server's innards. The primary downside is that you need some way to compute the crypto-signed bit. 4) You can keep a database of issued tokens along with when and why they were issued. 5) If you make it a habit of using a LHS that's descriptive, it's hard for a sender to argue that the tag was not assigned to them. It's particularly entertaining for things like e-pending because it will reveal which companies you will no longer choose to do business with. This turns out to be very powerful and very flexible. It can be extended to include functionality such as single-use addresses or limited-age addresses, etc. The big trick is to leverage the e-mail address field itself rather than trying to add a password or something like that in the body. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.