Stopping Abuse - Page 2

David MacQuigg · 28 Dec 2007, 02:58 AM

lavabit: We've taken the usual steps of limiting outbound messages, limiting the number of accounts that can be registered per IP subnet, and requiring a CAPTCHA, but nothing seems to be enough.

lavabit: When we lock out an abuser, we also lock out the /24 they registered from. If we see multiple subnets registering abusive accounts, we lock out the class B. In one case, we even locked out a Class A from (from an African ISP). While we think this has helped, the abusers keep coming.

There are two factors that determine how much abuse you will see - the cost of an account at your service, and the profit that spammers can make before the account is shut down. If the profit exceeds the cost, you will see abuse. Recently, Gmail is seeing a lot of abuse. Other free services like Yahoo and AOL are not.

For a cost estimate, I would include not just signup fees, but all costs, e.g. the cost of establishing a bank account, if that is required. For profit, I would just use an easy, but very rough estimate of 0.1 cents per spam. If a spammer can get 10,000 messages out before being shut down, he can expect one response and maybe $10 profit.

You should be able to shut an account down with as little as 100 spams. Looks like you are already enforcing rate limits. That should be total new recipients per day, not total messages. 100 would be more than enough for most new accounts. You need to respond quickly to spam reports. You could also do some simple filtering, like with SpamAssassin, to trigger an alert before the messages go out. Very thorough filtering, like with DSPAM, might reduce the need for 24/7 vigilance and rapid response to reports.

As for raising the cost, I know that there is great reluctance to charge even $1.00 for a "free" service, but you've got to get the total cost to spammers up in that range before they will leave you alone. Word puzzles won't do it. Everything on your signup page can be automated except the actual interpretation of the image, and those can be processed by shipping them in bulk to India, where they can be read for $.30 per hour. I have seen an ad for such a service!

I don't like any strategies the "collateral damage" category, including blocking entire netranges. Often, it causes collateral damage to innocent bystanders. It is effective only if there is not a cozy relationship between the spammer and the network owner. You can't do enough damage to force the network owner. The best you can hope is to get his attention.

Here is a suggestion. I haven't tried it, so maybe we could get some comments from other admins. Require a Paypal account for signup. If a new customer doesn't already have one, a link from your signup page will take him to Paypal's site, where there is an easy signup process, and a link back to your site. You can even have your own logo on Paypal's page, so it looks like a part of your website.

The strategy here is to take advantage of the work already done by the financial services industry, which has a lot more to lose than email services. To get a Paypal account, you need a bank account. Paypal verifies that account by making a small charge and a refund to the account. A legitimate customer will have no problem in providing a valid bank account number. A spammer will have to figure the cost of generating thousands of phony bank accounts. I expect they will go bother someone else.

Havokmon · 28 Dec 2007, 03:40 AM

Quote:

Originally Posted by David MacQuigg

Here is a suggestion. I haven't tried it, so maybe we could get some comments from other admins. Require a Paypal account for signup. If a new customer doesn't already have one, a link from your signup page will take him to Paypal's site, where there is an easy signup process, and a link back to your site. You can even have your own logo on Paypal's page, so it looks like a part of your website.

The strategy here is to take advantage of the work already done by the financial services industry, which has a lot more to lose than email services. To get a Paypal account, you need a bank account. Paypal verifies that account by making a small charge and a refund to the account. A legitimate customer will have no problem in providing a valid bank account number. A spammer will have to figure the cost of generating thousands of phony bank accounts. I expect they will go bother someone else.

I understand your suggestion, but I think the draw of 'free' is 'free'. A lot of people don't like paypal, and they don't want long signup hassles for a free service. There's a thread on this board about another provider who manually verifies new users - and it doesn't seem to be well-accepted. Sure, the less users you have, the less likely one of them will be a spammer - but that's not really what we're here for.

I find the best practice for mail is the same as for regular network security. You assume every client (not user) is a threat, and ensure that few if any security procedures happen on the client's side. You give them a username and password for access, but don't stop there. You still must assume they are a threat, so you put levels in place to prevent that threat from doing any damage to the systems they have access to. For example, in Visa CISP compliance, any system that has access to a machine which contains credit card data basically only has access to anything else on a 'business case' basis. Even though the card data is encrypted, you assume it's already been breached, and you make it as difficult as possible to send that data elsewhere. The machine containing the card data shouldn't be able to access anything other than getting updates. (I don't store card data - IMHO, that's just unnecessary)

This approach works well for me, as I've had a few spammers use valid credit cards to try and bypass the queue system. Since there is also a queue system for paying users, they get caught no matter what level user they are.

The first time I caught one, I called the card holder. I swear this woman was drugged out on something, and she openly admitted to giving her information to 'some guy who needed it'.

You just can't trust any client that has access to your systems.

George_B · 16 Jan 2008, 08:09 AM

you mentioned outbound limits but I haven't seen you mention filtering outbound e-mail.

I can't imagine the following not working for your free service:

1. Limit outbound to 15 recipients per hour
2. Limit total number of recipients per message to 10 ( qmail tarpit patch )
3. Filter outbound message

Havokmon · 16 Jan 2008, 09:55 PM

Quote:

Originally Posted by polarismail

you mentioned outbound limits but I haven't seen you mention filtering outbound e-mail.

I can't imagine the following not working for your free service:

1. Limit outbound to 15 recipients per hour
2. Limit total number of recipients per message to 10 ( qmail tarpit patch )
3. Filter outbound message

I think I mentioned it, maybe only in passing, but in my experience filtering outbound messages does not work. They just don't score high enough, and I don't want to start catching ham by accident. Then what - you end up making a 'possible spam queue' and sending out email requires a moderator? That's not good. HA. That's actually what I have now

The only difference is that for me, having the computer watch traffic patterns has been more accurate than filtering was.

With regards to limits, IMHO, that's far too restrictive - not that it wouldn't work, but the point is to run a service people want to/and can use. I am using tarpitting, it's higher than 10, but that doesn't deter Spammers very much - nor would I really think it should. The smart ones send small, text-only emails to start with. Breaking them up from 25/per to 10/per isn't a hassle for them. All you end up doing is hassling the free users who aren't very knowledgeable.
I would not consider limiting users to 15 recipients per hour. That would be a conversation killer. I DO have bandwidth quotas, so all these limits will be hit eventually, though that covers heavy users, not the short-haul spammer.

I think there are a couple basic rules to follow:
1. Don't compromise the user.
2. Don't trust any user.

I think it's just like security in any other environment. You need to allow users to do the task at hand, but at the same time, you cannot assume they won't do something out of bounds - intentionally or by proxy.

Following both rules is a thin line to walk, especially without human administrative interaction, but I believe my current solution is the best available for stopping spammers from abusing my service, while at the same time not putting excessive restrictions on individuals, and allowing me to have a life.

David MacQuigg · 17 Jan 2008, 03:02 AM

The limit should be 15 *new* recipients per hour. That would stop the spammers, but not block even a fairly rapid exchange with a normal recipient. You might also add incoming addresses, so that normal replies don't count against the rate limit.

The limit could be easily adjusted for the few users that have a legitimate need. You could also suggest a mailing list service for users who have repeated needs for large numbers of new recipients.

George_B · 17 Jan 2008, 06:45 AM

you guys are right. in the end it all depends what level of service they want/can offer to their free users.

Ideally there should be someone watching the queues 24x7 which is what we do but I'm not sure they can afford that if they generate no revenue to pay that person.

Filtering outbound is also quite bad because you really don't want to block by mistake real messages.

For companies that share the same domain, 70% of the traffic is in between them. It then becomes realistic to do this:

1. unlimited messaging between members of the same domain/group
2. 50 e-mails per hour to non-local recipients

how's that sound ?

Havokmon · 17 Jan 2008, 08:04 AM

Quote:

Originally Posted by polarismail

you guys are right. in the end it all depends what level of service they want/can offer to their free users.
For companies that share the same domain, 70% of the traffic is in between them. It then becomes realistic to do this:

1. unlimited messaging between members of the same domain/group
2. 50 e-mails per hour to non-local recipients

how's that sound ?

David's Solution is excellent. I was thinking one way to implement it would be a simple table-per-domain in SQL. You then have two columns:
sender,receiver

When they send, you just do a query for each recipient:
select count (*) from domain_table where `receiver` not in (receiver_array) and `sender` = smtpauth_name

Then you go back to your user auth table, and
select totalthishour from authtable where username = smtpauth_name
add those two together, see if they're greater than 15. If they are, deny smtp. (This assumes you have a query run hourly that zeros out all the counts - OR probably better, do some timestamp magic with a 'last sent' timestamp field)
Either way, then add those recipients to your domain_table for that user.

For your entire domain 'allow', I think you could do some SQL magic, and keep the same query but match on domain name.... I honesty don't want to think that hard right now

If you don't have a ton of traffic, the queue thing I do might be better. I don't actually monitor the queue, I just wait for a message that the threshold has exceeded, and take it from there. Plus I can use existing queue tools to see how many emails are in queue, so there isn't a lot of processing - either for the system, or your brain trying to figure out how to implement this

David MacQuigg · 20 Jan 2008, 06:30 AM

There is an interesting discussion on the [spf-discuss] forum relating to who is actually responsible for sending the spam when there are two actors involved - the Transmitter (as identified in the HELO name) or the original Sender (as identified in the Return Address). These are normally in the same domain, but there can be two domains involved when we are talking about a large email service that might handle outgoing mail for many smaller domains. Part of the problem is we can't even find the right words to describe the different actors and roles. I introduced the term Transmitter to mean specifically the last Agent on the Sender's side.

For a nicely organized, threaded view of the discussion see http://news.gmane.org/gmane.mail.spam.spf.discuss See the thread starting with Frank Ellermann's post on Jan 18th, "Terminology, ADMD, MON, roaming ..."

Gmane nicely preserves the spacing of characters, which makes it one of the few archives which can display text diagrams like:

Code:

|----------- MON -----------|           |---------- MRN ---------|
                                   /
Sender(s) ==> MSA/Transmitter --> / --> Receiver/MDA ==> Recipient
                                 /
                              Border

28 Dec 2007, 02:58 AM	#16
David MacQuigg Member Join Date: Aug 2006 Location: Tucson AZ Posts: 66 Representative of: Open-Mail.org	Stopping Abuse of Free Email Services lavabit: We've taken the usual steps of limiting outbound messages, limiting the number of accounts that can be registered per IP subnet, and requiring a CAPTCHA, but nothing seems to be enough. lavabit: When we lock out an abuser, we also lock out the /24 they registered from. If we see multiple subnets registering abusive accounts, we lock out the class B. In one case, we even locked out a Class A from (from an African ISP). While we think this has helped, the abusers keep coming. There are two factors that determine how much abuse you will see - the cost of an account at your service, and the profit that spammers can make before the account is shut down. If the profit exceeds the cost, you will see abuse. Recently, Gmail is seeing a lot of abuse. Other free services like Yahoo and AOL are not. For a cost estimate, I would include not just signup fees, but all costs, e.g. the cost of establishing a bank account, if that is required. For profit, I would just use an easy, but very rough estimate of 0.1 cents per spam. If a spammer can get 10,000 messages out before being shut down, he can expect one response and maybe $10 profit. You should be able to shut an account down with as little as 100 spams. Looks like you are already enforcing rate limits. That should be total new recipients per day, not total messages. 100 would be more than enough for most new accounts. You need to respond quickly to spam reports. You could also do some simple filtering, like with SpamAssassin, to trigger an alert before the messages go out. Very thorough filtering, like with DSPAM, might reduce the need for 24/7 vigilance and rapid response to reports. As for raising the cost, I know that there is great reluctance to charge even $1.00 for a "free" service, but you've got to get the total cost to spammers up in that range before they will leave you alone. Word puzzles won't do it. Everything on your signup page can be automated except the actual interpretation of the image, and those can be processed by shipping them in bulk to India, where they can be read for $.30 per hour. I have seen an ad for such a service! I don't like any strategies the "collateral damage" category, including blocking entire netranges. Often, it causes collateral damage to innocent bystanders. It is effective only if there is not a cozy relationship between the spammer and the network owner. You can't do enough damage to force the network owner. The best you can hope is to get his attention. Here is a suggestion. I haven't tried it, so maybe we could get some comments from other admins. Require a Paypal account for signup. If a new customer doesn't already have one, a link from your signup page will take him to Paypal's site, where there is an easy signup process, and a link back to your site. You can even have your own logo on Paypal's page, so it looks like a part of your website. The strategy here is to take advantage of the work already done by the financial services industry, which has a lot more to lose than email services. To get a Paypal account, you need a bank account. Paypal verifies that account by making a small charge and a refund to the account. A legitimate customer will have no problem in providing a valid bank account number. A spammer will have to figure the cost of generating thousands of phony bank accounts. I expect they will go bother someone else.

20 Jan 2008, 06:30 AM	#23
David MacQuigg Member Join Date: Aug 2006 Location: Tucson AZ Posts: 66 Representative of: Open-Mail.org	Responsibility for Stopping Abuse There is an interesting discussion on the [spf-discuss] forum relating to who is actually responsible for sending the spam when there are two actors involved - the Transmitter (as identified in the HELO name) or the original Sender (as identified in the Return Address). These are normally in the same domain, but there can be two domains involved when we are talking about a large email service that might handle outgoing mail for many smaller domains. Part of the problem is we can't even find the right words to describe the different actors and roles. I introduced the term Transmitter to mean specifically the last Agent on the Sender's side. For a nicely organized, threaded view of the discussion see http://news.gmane.org/gmane.mail.spam.spf.discuss See the thread starting with Frank Ellermann's post on Jan 18th, "Terminology, ADMD, MON, roaming ..." Gmane nicely preserves the spacing of characters, which makes it one of the few archives which can display text diagrams like: Code: \|----------- MON -----------\| \|---------- MRN ---------\| / Sender(s) ==> MSA/Transmitter --> / --> Receiver/MDA ==> Recipient / Border

16 Jan 2008, 08:09 AM	#18
George_B Cornerstone of the Community Join Date: Jan 2008 Posts: 709 Representative of: PolarisMail.com	you mentioned outbound limits but I haven't seen you mention filtering outbound e-mail. I can't imagine the following not working for your free service: 1. Limit outbound to 15 recipients per hour 2. Limit total number of recipients per message to 10 ( qmail tarpit patch ) 3. Filter outbound message

17 Jan 2008, 03:02 AM	#20
David MacQuigg Member Join Date: Aug 2006 Location: Tucson AZ Posts: 66 Representative of: Open-Mail.org	The limit should be 15 new recipients per hour. That would stop the spammers, but not block even a fairly rapid exchange with a normal recipient. You might also add incoming addresses, so that normal replies don't count against the rate limit. The limit could be easily adjusted for the few users that have a legitimate need. You could also suggest a mailing list service for users who have repeated needs for large numbers of new recipients.

17 Jan 2008, 06:45 AM	#21
George_B Cornerstone of the Community Join Date: Jan 2008 Posts: 709 Representative of: PolarisMail.com	you guys are right. in the end it all depends what level of service they want/can offer to their free users. Ideally there should be someone watching the queues 24x7 which is what we do but I'm not sure they can afford that if they generate no revenue to pay that person. Filtering outbound is also quite bad because you really don't want to block by mistake real messages. For companies that share the same domain, 70% of the traffic is in between them. It then becomes realistic to do this: 1. unlimited messaging between members of the same domain/group 2. 50 e-mails per hour to non-local recipients how's that sound ?