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

Leen Besselink leen at consolejunkie.net
Thu Oct 7 23:00:46 UTC 2010


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





More information about the NANOG mailing list