Re: New hijacking - Done via via good old-fashioned Identity Theft

[Leen Besselink <leen () consolejunkie net>]

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)