Discussion re sg development. You don't have to be a developer.


Postby Guest » Fri Aug 29, 2003 1:41 pm

By: jqh1 ( Josiah Hamilton )
2003-02-08 10:23
Probably the most requested feature these days is the ability to send unsolicted messages from sg addresses.

Seems like the most straightforward way would be to do a couple of things:

1) add the getRedirectedAddress functionality to the website, so that a user could get one for a given disposable address and intended 3d party recipient, and

2) give the user the ability to create a new disposable address in the user interface, without the need to have one auto-created (code will be easy, my biggest fear is that doing this will further obscure the primary benefits of sg by causing new users to think that all addresses must be created this way)

In any event (even in the absence of unsolicited messages), I'm trying to come up with a throttling mechanism that will either prevent the user from obtaining a large number of redirected addresses in a short time or prevent the user from sending a large number of unsolicited messages in a short time or preferably both. The latter is probably more important, so I'll focus on that:

I think throttling would be a lot easier to implement in SysKoll's code because of the ability to maintain state in memory. Since the other versions are stateless, we'd need to maintain information in the database. I'd love to only have to add one column to the Users table in that case (or somehow manage to do it with exisiting columns).

I'm thinking that throttling would be easiest to manage if it were expressed in terms of a number of messages per time period -- eg, 100 messages per day or 10 messages per hour or something. If these values could be specified in the config file, all the better.

There is such a huge gap between acceptable use of the system and unacceptable use of the system that I think it'll be easy to enforce a throttle rate beyond which we have no problem simply ignoring messages -- that is, if the rate is tuned right, I don't think we'll have the need to send an error to the user to inform him or her that the rate has been exceeded. Put another way, 100 or 200 messages per day is a comfortable (even extravagant) limit for users, but is pitifully inadequate for spammers.

Any thoughts on the logic / data model to do this?

By: syskoll ( Fred )
RE: throttling
2003-02-10 13:12

The throttling would be very easy to implement anywhere. Assume you have a counter in the user row, initialized to, say, 500. You decrement it each time an unsollicited (non-reply) message is sent from SG. When counter reaches 0, display nice message such as "That was your last message for the day" (and probably log it too since it's a highly abnormal event). At 3AM every day, run a job that locks every user row, resets the counter to 500, unlock the row and so on for the whole table. Shouldn't hamper the regular SG operations.

Unfortunately, we still have a problem: What prevents Joe Spammer to create 10,000 new SG user accounts from a script and use all 10,000 to spew 10K*500 = 5 million spams a day? An easy way to do that would be to register a domail and use, as forwarding addresses, to script running on the host could easily generate the proper answers and get the forwarding address verified.

-- SysKoll

Return to Developers

Who is online

Users browsing this forum: No registered users and 1 guest