This content was published by Andrew Tomazos and written by several hundred members of the former Internet Knowledge Base project.
Seeded generation
Comments from Philip Trauring , Jerusalem , Israel :
( A ) I think it would be helpful if the password would be generated using an algorithm that need not be run on the server itself . i . e . the software for generating the password could be run on a cell phone or PDA , using a seed file of some kind from the server and whatever else it needs ( perhaps the password is dependent on the name of the person receiving the address ). You ' re at your bank , or at a party , or whatever , and you run the program , enter the name of who it ' s going to , and it generates an e - mail address . You can even enter in more information than goes into the address ( like the person ' s full name , e - mail address , etc .) and then sync that data into your address book later .
[This is a good suggestion. My fear of it lies in the ability to hack it, and/or in the seed being exposed taking down the whole system. Perhaps leave this for a version 2. AT]
[I don't see why this is any more likely to be hacked. In the case of the algorithm and seed residing on a PDA or phone, it would seem unlikely that those would be hacked. In the case of the server, it has the same likelyhood of being hacked as before, no? Doesn't the advantage of being able to give out addresses anywhere outweigh the disadvantages? PT]
( B ) It seems like there should be some way for other people to give out your address . You said at the very least you ' ll always know who you gave the address to , but there ' s at least one simple way to allow people to give out your address and have the person be able to get their own e - mail address from your system . You can have two types of addresses , linked and non - linked addresses . Linked addresses are linked to the other person ' s specific e - mail address . You wouldn ' t even need to know what the person ' s e - mail address was when you give them the linked address , as the server could just automatically link it to the first address it receives an e - mail from . Then , when you receive an e - mail headed for a linked address , but that does not come from the linked address , it can do a few things :
1 ) Create a challege / response that requires the person to go to a web site and enter their contact information . The system can then generate a new address for them on the fly or :
2 ) Send a message to you that a new person has e - mailed you , and showing you the message , allowing you to verify if you want that person to receive their own address , or blocking them .
A non - linked address could be given out to entities that you know will not be consistently sending you e - mails from the same address , for example your bank . In this case , you might be able to restrict to to specific domains , even telling your server to add only the first domain , and querying you each time a new domain shows up ( i . e . the first e - mail comes from service @ bankofamerica . com and another comes from customersupport @ support . bankofamerica . com - should e - mails be accepted from support . bankofamerica . com ?) or even just asking each time a new e - mail address is used , if you should add it to that ' account ' as verified .
[This is another good suggestion. I think for version 1 we will default allow people to share addresses, and then the user can choose to block or rotate when a third party contacts them. AT]
[To me the great advantage of this system is that each person contacting essentially is contacting a different address. The idea of sharing defeats the purpose to some extent, and I'd rather be able to generate a new address for each person, which isn't too difficult.
In any event, I also would caution the "we'll get to that in 2.0" process. If you really want to develop a replacement for existing e-mail infrastructure then we should work out all the details in the beginning and develop a full system from the get go. It won't help the cause if people try it out but find it doesn't work well enough and then don't try again. PT]
C ) In a similar vein , there should be a way to , in a standard fashion , request an e - mail address from you . This assumes some familiarity with the system , after it takes over the world and changes the way everyone uses e - mail . :-) Let ' s say your mail goes to john . doe . com . Sending an e - mail with your contact information to request @ john . doe . com would send john doe a message requesting an e - mail address and showing who it is , whereupon john doe could either click a link and immediately generate an e - mail address for the person , or preferably send the person to a web site that would require them to fill in their contact info ( first name , last name , e - mail address , optionally other stuff ) and then send it back to you to be verified . You could also use this as the address you put on your business card . In order to prevent spam from flooding request @ john . doe . com ( and thus sending you tons of bogus requests ) you can require that the subject ( or body ) of the e - mail be something specific , such as :
1 ) a standard word like ' request ' ( risky because spambots might learn this )
2 ) the owner ' s full name , in this case ' john doe ' ( insures people know you , but also open to automated spam in some cases where your address is given out by someone who knows you )
3 ) a coded word or number , that you can print on your business card or post on your web site , etc . that needs to be in the subject or body . This could be abused by a real person , but presumably would be very difficult for a spambot to figure out ( on the web you could even provide the code as an image , or one of those obscured images ).
[This coded word or number could be integrated into the email address. If you wanted to do this you could just create a general entry. First contact from an unreffered source is really tricky. AT]
[the problem with integrating it into the e-mail address in a standard fashion is the ability for spambots to learn how the code is in the address. By making it separate, no bot would be able to figure it out. PT]
D ) I don ' t see the need to put your name in the e - mail address if it ' s already in the domain . I ' d rather just have the name of the person who is sending the e - mail , including their last name so I don ' t get people mixed up .
[The spec is changing to allow multiple Segmail users under one domain, as per other suggestions. You are right the john-*@john.* is redundant. AT]
Back to Index