pressure valve throttling

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

Informing users when they maxreccount is reached

Postby SysKoll » Tue Feb 17, 2004 10:41 pm

I suggest that when spameater detects that maxreccount is reached (last message has been forwarded and count has just reached the limit), it fires an email to the user with "Subject: WARNING: spamgourmet's maximum message count reached" and a body saying: "The maximum number of messages (currently $maxreccount) was received on your address $disposable within an hour. Messages will be eaten for the remaining of the bour."

Since we have the time values handy, we can be more precise, eg display "Messages will be eaten for the next " . ($sendthrottleinterval + $throttleTime - $now)/60 . " minutes."

($sendthrottleinterval + $throttleTime - $now) is the remaining time during which the account will stay disabled, as shown by this little illustration:

Code: Select all
                           now
       throttleTime         |    R
                |           |<------->
time -----------|-----------|--------|------>
                <-------------------->
                 sendthrottleinterval

[/code]

This warning email will make the user understand what's going on.
-- SysKoll
SysKoll
 
Posts: 889
Joined: Thu Aug 28, 2003 9:24 pm

Postby josh » Fri Feb 20, 2004 5:30 pm

latest on this is that we have a test version of spameater running where we're trying to tweak the throttling code. Once it seems like it's working (it kind of does now), we'll add the warning message.
josh
 
Posts: 1371
Joined: Fri Aug 29, 2003 2:28 pm

Postby josh » Sat Feb 21, 2004 9:21 pm

The most recent test with the new throttling code pretty much worked - it lets one extra message through:

throttle was set to 10 msg within the 2 hours (test env :))
script sent 22 messages to address with 15 messages
11 messages got through, other 11 were stopped by rec throttle
message count decreased to 4 (15 minus 11)

I fixed a bug where the count was being decreased even though recthrottle stopped the message.
josh
 
Posts: 1371
Joined: Fri Aug 29, 2003 2:28 pm

Postby SysKoll » Sun Feb 22, 2004 5:51 am

Josh,

Cool. Sorry I didn't have much time to help with the test. Is the warning message implemented?
-- SysKoll
SysKoll
 
Posts: 889
Joined: Thu Aug 28, 2003 9:24 pm

Another scenario

Postby SysKoll » Fri Mar 05, 2004 4:42 pm

See http://bbs.spamgourmet.com/viewtopic.php?t=167 for another interesting scenario involving looping:

  • Spammer creates a non-SG email account A
  • Spammer creates SG account S, makes A a truster sender
  • Spammer has A forward to S
  • Spammer subscribes address A to a gazillion mailing lists
  • For fun, same as above, with A the forwarding address of S.


This is one of the nastier scenarios I've heard. It will be avoided by the throttling. Josh, we need to get it working ASAP.
-- SysKoll
SysKoll
 
Posts: 889
Joined: Thu Aug 28, 2003 9:24 pm

Postby maratheamit » Fri Mar 05, 2004 6:21 pm

Throttling is the way to avoid a lot of DoS problems. So we should first daemonize the spameater process and then it becomes very easy to add the throttling code as we can maintain state in the daemon.

In the short term, is there any benefit to adding an "X-SeenBefore" header to messages forwarded by SG?
maratheamit
 
Posts: 82
Joined: Fri Aug 29, 2003 2:35 pm

Postby SysKoll » Fri Mar 05, 2004 9:11 pm

Amit,

Actually, we don't need to demonize spameater to do this. Throttling can be implemented with 2 extra counters in the DB.

What would be the semantics of the "X-SeenBefore" header?
-- SysKoll
SysKoll
 
Posts: 889
Joined: Thu Aug 28, 2003 9:24 pm

Postby maratheamit » Fri Mar 05, 2004 9:45 pm

Yes, I also realized later that throttling is independent of daemonization.

As for the new header, it is something I was suggesting as a stop-gap measure. It is not foolproof but if we are really worried about attacks on SG we can implement it quickly.

Semantics: we look for this header after we have parsed the message. If it is present we drop the message on the floor. Otherwise, we add this header and process the message as before.

This does not protect against someone deliberately removing the special header. But then this is not meant to be a permanent solution.
maratheamit
 
Posts: 82
Joined: Fri Aug 29, 2003 2:35 pm

Postby James Day » Mon May 17, 2004 2:07 pm

>> message count decreased to 4 (15 minus 11)

I have some reservations about this. If the assumption is DOS, perhaps it's better to also cover the possibility of DOS against the SpamPal account and decrease the count by just 1 to make the DOS less effective? Would let more emails to a spammer using it as a drop box get through, though.
James Day
 
Posts: 8
Joined: Sat Aug 30, 2003 1:44 pm

Previous

Return to Developers

Who is online

Users browsing this forum: No registered users and 1 guest

cron