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 k...@domain.tld to user1 and k...@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: k...@domain.tld for when you have a personal domain key-u...@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 > b...@example.com (no matter from which email address) > > sending person/maillist 2 gets password 123545 to send to > b...@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) > >
