bbs.spamgourmet.com

First -- I meant to post this 6 months ago -- Alan Iwi has come up with a spam harvester trap with teeth, using spamgourmet for the transport. Check out http://home.badc.rl.ac.uk/iwi/cgi-bin/harvest/trap. This is an example of auto-address creation that's not only not contrary to the spamgourmet terms and conditions, but is pretty sweet!

The new code seems stable after a few days, which is good - had to tweak it a bit to handle the load, but no big problems. We got some new domains -- two *three* character ones: 0sg.net and 9ox.net (that's a zero in the first one, and an 'o' in the second one), a four character one, a-bc.net, and, if you want to let your counterparty know exactly what you're up to, you can use disposableaddress.com.

Wow... I just might make up a trap like that! It would give me a good reason to get back into Perl...

I don't understand what's so sweet about it. Didn't you just say it was contrary to Spamgourmet's rules?
After all, it generates endless addresses!

A couple more of these traps and we'll have another outage.

And what good comes from it? The "from" headers of the spammers would naturally be fake. As for the IP addresses, even if they are legit, what will Iwi do with them? Report them to the FBI...?

lwc wrote:I don't understand what's so sweet about it. Didn't you just say it was contrary to Spamgourmet's rules?
After all, it generates endless addresses!

According to the TOS:

(o) in a way that consumes resources in a manner grossly disproportionate to that of other users of the service, including, but not limited to the use of scripting or other automated means to create large numbers of accounts or addresses over a short period of time.

Emphasis on "scripting ... to create large numbers of ... addresses". This trap does not create the addresses, it generates them. The spammer is the one creating them.

At first I thought what you did -- that he said it's against the rules. Let me bold the part that I missed at first glance too:

info wrote:This is an example of auto-address creation that's not only not contrary to the spamgourmet terms and conditions, but is pretty sweet!

lwc wrote:A couple more of these traps and we'll have another outage.

I really doubt that... the traffic from this one account will probably never exceed 1/100th of the total sg traffic.

lwc wrote:And what good comes from it? The "from" headers of the spammers would naturally be fake. As for the IP addresses, even if they are legit, what will Iwi do with them? Report them to the FBI...?

No, to their ISP. Most ISPs have a no-spam policy. If their ISP doesn't, we can go further up the chain, possibly ending with ARIN, and therefore possibly getting the ISP's entire IP block yanked out from under them.

It's really down to usage, and the probability that such a trap won't create a large number of addresses. Harvesting is frequent, but not, AFAICT, anywhere near the scale that we see when someone is scamming an online lottery or coupon offer, for instance.

Where can I download this file to put on my web site?

Cray wrote:Where can I download this file to put on my web site?

Chances are good that you can't. On the site it says that it embeds a "security key" in the address so he knows it wasn't spoofed. If he released the source code, there goes the security key algorithm, and with it goes the spoof protection.

I've written a similar trap, and I'm not going to release it either -- until I've had my fun with it, that is. Then I'll likely give it to only one person. The security of any protection method (public/private key encryption aside) depends on the algorithm's secrecy, especially when you only have 20 characters to implement it in.

If you know Perl, it's pretty easy to write your own. I did it in about 2-3 hours. The basic idea is that you take the IP address, convert it to an integer (you can either do something like eval($ip) or something more robust like $ip = 0; $ip = ($ip << 8) + $_ for split /\./, $ip;), get the current time as an integer (via the time function), and pack them into an 8-byte string with pack("NN", $ip, $time). Then you either derive a security key from that (which is what this guy did) or encrypt it (which is what I did). Then just run it through base64, s#+/#-_# and s/=+$// to make the address easier for MTAs to handle, and tack it on the front of ".number.user@spamgourmet.com".

Then, obviously, you have to write a program that does the exact opposite of all that, so you can "read the addresses" when they get used.

And if that all makes no sense to you... sorry for confusing you. =]

crazycomputers wrote:

If he released the source code, there goes the security key algorithm. . .

I'm not so sure about this one. When I read the writeup that came with my PGP 2.6.3 package [from Finland], the author seemed to suggest that a suitable encryption algorithm CAN be public and still not be broken - even if the MESSAGE being encrypted [the 20 character spamgourmet 'word'] is very short. Has this fellow implemented a PGP - style algorithm in the spamtrap?

By the way, isn't the link to spamgourmet on this guy's site a mistake? Every harvester robot would take a shot at spamgourmet, harvesting the 'info' email, the sample emails, and generally probing the site. Shouldn't spamgourmet also have a spam trap? Shouldn't the spamgourmet link be an image, or a form pushbutton?

crazycomputers wrote further:

. . .you only have 20 characters to implement [the security key].

It turns out this is not true, either.

GUESS WHAT, EVERYBODY:
You can use very long phrases as the 'words' and 'numbers' in spamgourmet disposables, AND THEY GO THROUGH SPAMGOURMET IN BOTH DIRECTIONS JUST FINE, ADDRESS MASKING AND ALL.

I tested the following:

Code: Select all

testaverylongsentencetoexceedtwentycharacters.
averylongsentencetoexceedtwentycharacterswithavengeance.myaccountname ['at' sign] spamgourmetdomain ['dot'] com

AND IT WORKS!!

The message count for this disposable was obviously ONE, since the first character of the 'number' was the letter 'a'.

After I reset the message count, I was able to send myself another email via the same disposable, but with a different phrase in the 'number', as follows:

Code: Select all

testaverylongsentencetoexceedtwentycharacters.
completelydifferentdatainplaceofthenumberstillexceedingtwentycharacters.
myaccountname ['at' sign] spamgourmetdomain ['dot'] com

This second email, with the new 'number' phrase, was forwarded with that phrase intact. I was able to repeat this process several times - each message counting against the same disposable, but containing a different 'number' phrase.

Address masking for a disposable ALWAYS reverts to the characters used when the disposable was first created. In the example above, when I replied to myself using address masking, the disposables always reverted to:

Code: Select all

testaverylongsentencetoexceedtwentycharacters.
averylongsentencetoexceedtwentycharacterswithavengeance.
myaccountname ['at' sign] spamgourmetdomain ['dot'] com

just the same as the first disposable above.

Disclaimer:
I only made 5 tests. I did not attempt to measure the absolute character limit of the 'word' or 'number' fields. All test exchanges were with an email completely unrelated to the protected address; there was no chance of interaction between spamgourmet and the simulated outside party.

Conclusion:
I think you can start transmitting all kinds of interesting info in your disposables. For the harvester trap, you could even use the SAME disposable for all trappings, and just put code [maybe A LOT of code] in the 'number'. Since you would never reply to the trap-generated disposable, the reversion is irrelevant.

EDIT: fixed the formatting which was giving us uncomfortably long lines

The same Guest wrote:GUESS WHAT, EVERYBODY:
You can use very long phrases as the 'words' and 'numbers' in spamgourmet disposables, AND THEY GO THROUGH SPAMGOURMET IN BOTH DIRECTIONS JUST FINE, ADDRESS MASKING AND ALL.

The SMTP standard limits the local part to 64 characters. You may succeed with longer ones (as you oviously did), but the next relay may refuse to transfer your mail.

Aah-Hah!!

Is the 'local part' everything to the left of the 'at' sign?

The 'local part' would include the periods used by spamgourmet between the 'word', 'number', and 'accountname'?

Assuming the answer to both questions is yes, I would have to amend the suggestions in my prior post:

'...use a very short or single digit 'word' for your spam trap, and create a verification code, transmitted as the 'number' of your disposable, with a length not to exceed 64 - 'word' length - 'accountname' length - 2 [periods].'

This is still a lot longer than the 20 characters suggested for the 'word' on the spamgourmet website.

Would use of 'words' or 'numbers' longer than 20 characters [but, of course, forming a 'local part' of less than 65 characters] foul up the spamgourmet server in any way?

Anonymous wrote:

crazycomputers wrote:If he released the source code, there goes the security key algorithm. . .

I'm not so sure about this one. When I read the writeup that came with my PGP 2.6.3 package [from Finland], the author seemed to suggest that a suitable encryption algorithm CAN be public and still not be broken - even if the MESSAGE being encrypted [the 20 character spamgourmet 'word'] is very short. Has this fellow implemented a PGP - style algorithm in the spamtrap?

Yes, it can be public without being insecure, but it must be asymmetric. PGP/GPG wouldn't work very well here, since it has to add a header to the data specifying who it's from, who it's to, the version of PGP/GPG, blah blah blah. Using this is a sure-fire way to exceed 20 characters. I encrypted a 15-byte file with GPG, without signing or ASCII armoring, and it came out a 607-byte file.

Unless the author wrote his own asymmetric algorithm (which is usually done by major math-heads) or found one that doesn't add information, it's symmetric, and making it public would destroy the security.

When you're limited to 20 characters, there isn't a lot of room to fool around with.

Anonymous wrote:

crazycomputers wrote:. . .you only have 20 characters to implement [the security key].

It turns out this is not true, either.

Let me rephrase that.

You only have 20 characters to reliably implement [the security key].

I encrypted a 15-byte file with GPG, without signing or ASCII armoring, and it came out a 607-byte file.

Unless the author wrote his own asymmetric algorithm (which is usually done by major math-heads) or found one that doesn't add information, it's symmetric, and making it public would destroy the security.

Dude. Why on earth would you need an asymmetric cipher?

Use a symmetric cipher (DES, RC4, RC5, whatever). Pick a random key. For every spammer, encrypt the IP, time, etc. with that random key. Convert from binary to ascii and append to front of spamgourmet email address.

This code can be distributed to anybody; each person just picks their own key.