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 way when you registered at that webshop or mailinglist and that e-mail address gets used for spam, you just delete that one unique key (and maybe, if you still want to communicate with them, a new unique key). There are 2 variants if I remember correctly: key@domain.tld for when you have a personal domain key-user@domain.tld for when you have a server which understand address extensions While there is software for that, I've been doing something similair to this by hand for a long time for a lot of contacts. The good thing about using a unique e-mail address instead of a password is that you can block at the SMTP-level, without even receiving an e-mail body. Have a nice day, Leen.
each potential person that can send email to your email address, gets a unique password from you.
sending person/maillist 1 gets password abcdefg to send to bla@example.com (no matter from which email address)
sending person/maillist 2 gets password 123545 to send to bla@example.com (no matter from which email address)
email clients should be modified to include the password: field both in the email itself and in the header entry field (to: from: subjecT: or just store them together with the destination address in the address book
mailservers (the maildrop part) should be modified to parse the Password: header, compare it to the list of currently allowed passwords for the destination email address and then either drop to the mailbox, or bounce. (we did this in our test setup by simply parsing the entire email, so the password could be -anywhere- in the email :P
ofcourse the Password: line should be only sent to the recipient, not to other Cc: or Bcc: target addresses of the same email, the first stmp server in the chain should solve this bit.
actually, durign our tests, we turned off all the header verifications, RBL's, etc on our smtpds, and the only spam that got through were emails that accidentially contained the password string in a binary attachment (as we parsed the entire email .. we should not do that, just teh Password: line in the final version :P and stuff where we gave, for example, nanog, the password "nanog" and then nanog is cc'ed in a spam both of which cases can be solved with the standardization of the Password: field
once this is in place, all smtpds can go open relay again, port 25 can be opened again on eyeball networks, RBLs and graylisting can remain at home, and the SMTP email system will be 100% spam free and reliable and real-time. (there are several other features which have been removed from most smtpds to "stop spam" such as accepting ip addresses rather than domain names in the target email address, which can then return)
all the other stuff never stopped spam, it just made smtp email unreliable slow and no longer an option for 99% of the things where email was used for before, and skype, msn and facebook are used for today.
this system -does- stop spam, but the disadvantage to this system is that by implementing it, smtp email is no longer suitable for "initial contact"
(well you could ofcourse place passwords in whois and on your website for your hostmaster/sales box so random people can still make initial contact over smtp, or simply accept all passwords on those boxes, on which then there WILL be spam.. ;)
i'd say, smtp no longer being "open for any random idiot to mail any other random idiot without knowing each other first" is less of a disadvantage than taking the whole thing slowly die by making it less and less attractive as a means of communications (slow, unreliable and not real-time, and still with spam coming in by the 1000s, which it is due to "conventional" attempts to stop spam)