Ok, well I had my first spam client. I never knew how pissed I could get tell now. I was working on my plesk automation script. It sends me a email when its done workin, and I been testing it for the last hour or so. My most recent test, the mail was taking more then 2 min to get to me(it took like 20-10 secs before) I first thought it was a problem in the script. ps ax told a whole different story. mass emails just pouring out. Long story short I cut the users access. What do I do now? I only found it this time because my mail wasent sending. What do you do to stop it from going on and on. As usual this was done via a cgi script. Thanks for any suggestions.

The simplest, and arguably best, solution is simply to limit each account to a certain number of emails/day -- say, 500, or maybe 1000.

Any normal user who sends more than 1000 emails/day ... well, isn't normal. And given that 24 hours is more than enough time for complaints to arrive and for you to cancel the offending account, there really isn't any profit to be made by spammers if you do this.

How would I go about doing that, any ideas? Thanks

My prefered solution, with qmail, is to

chmod o-x /var/qmail/bin/qmail-queue
mv /var/qmail/bin/qmail-queue /var/qmail/bin/qmail-real-queue
install -m 2511 qmail-queue-auth /var/qmail/bin/qmail-queue

where qmail-queue-auth inspects getuid() and, if getuid()<100, $USER, and decrements a counter, returning a temporary queuing faliure if the counter reaches zero.

The general idea should apply to any MTA: make the actual MTA unexecutable by normal users, and add a sgid wrapper in its place which authenticates the fact that the calling user is allowed to send email.

how about with exim :D

Originally posted by Synergy
how about with exim :D

Ick. Why are you using exim?

More seriously, it should be possible to do the same thing with exim, at the expense of spending lots of time reparsing the command line to work out if an invocation is sending a message or doing something else.

With exim, it would probably make more sense to write a patch rather than trying to wrap it up.

Here's a very brutal solution I implemented a while ago using mail queues; it's ugly, any enhancement suggestion is welcome:

Dans crontab:


*/1 * * * * /mypath/maildog


maildog.c content:


#include <dirent.h>
#include <stdio.h>
#include <stdlib.h>
#include <fcntl.h>
#include <time.h>

#define THRESHOLD 50
#define QUEUE_PATH "/var/spool/mqueue"
#define SHUTCMD "/etc/rc.d/init.d/sendmail stop > /dev/null"
#define KILLCMD "/usr/bin/killall -q -w -KILL sendmail"
#define TRACEFILE "/var/log/maildog"
#define VICTIM "/usr/sbin/sendmail"
#define WITNESSPROT "/bin/mv -f /usr/sbin/sendmail /usr/sbin/bugger"


#define OK 0
#define ERR_PANIC 1
#define ERR_TOOMANY 2
#define ERR_DEADJIM 10

int checkSendmailUp()
{
FILE *f;
f = fopen( VICTIM, "r" );
if ( 0 == f )
return ERR_DEADJIM;
fclose( f );

return OK;
}

int countMsgsInQeue()
{
DIR *dirp;
struct dirent *dp;
int howmany = 0;

if ((dirp = opendir( QUEUE_PATH )) == 0)
{
return ERR_PANIC;
}

for (dp = readdir(dirp);
dp != 0;
dp = readdir(dirp))
{
if ( ++ howmany > THRESHOLD )
{
closedir(dirp);
return ERR_TOOMANY;
}
}

closedir(dirp);
return OK;
}

void shutdownSendmail()
{
FILE *f;
time_t t;
struct tm *tt;
char logtime[32];
int ret;
// Trace
time( &t );
tt = localtime( &t );
sprintf( logtime, "%02d-%02d-%02d %02d:%02d:%02d",
tt->tm_mon, tt->tm_mday, tt->tm_year,
tt->tm_hour, tt->tm_min, tt->tm_sec );
f = fopen( TRACEFILE, "a+" );
fprintf( f, "%s: Shutting down Sendmail..........", logtime );
// Bye now
ret = system( SHUTCMD );
if ( OK == ret )
fprintf( f, "OK\n" );
else
{
fprintf( f, "Failed.\n" );
fprintf( f, "%s: Forcing down Sendmail..........", logtime );
ret = system( KILLCMD );
if ( OK == ret )
fprintf( f, "OK\n" );
else
fprintf( f, "Failed.\n" );
}
// How about a new identity...
fprintf( f, "%s: Witness protection program......", logtime );
ret = system( WITNESSPROT );
if ( OK == ret )
fprintf( f, "OK\n" );
else
fprintf( f, "Failed.\n" );
// Clean-up
fclose( f );

}

int main( int argc, char ** argv )
{
if ( OK != checkSendmailUp() )
return 0;
if ( OK != countMsgsInQeue() )
shutdownSendmail();

return 0;
}

Not to play devil's advocate, but I regularly send out well over 1000 e-mails per day via a cgi script. The number of subscribers to my various & asst. mailing lists is around 3000 now. It's not spam, it's all opt-in. Hard-earned opt-ins through great customer service and grassroots one-on-one cultivating.

Thank heavens my upstream doesn't limit the # of e-mails I can send out per day, because ESPECIALLY this time of year, with the nutty holiday season here and my shopping cart nearly smokin' from activity, I'd be REALLY irritated if my upstream limited my Legitimate advertising.

I understand there are problems with spammers, just be wary of pinching the legitimate clients for the sake of the 5% rotten apples. :)

Just food for thought from
:D Bailey

Originally posted by baileysemt123
Not to play devil's advocate, but I regularly send out well over 1000 e-mails per day via a cgi script

I'm sure that there are a few people like yourself. On the other hand, your web host probably knows who you are, right?

There is no reason why per-user email limits should be the same across the entire server; personally I'd set them at different levels for different accounts by default, and if/when a user used more than half their daily quota (or, even worse, hit their quota) I'd find out why, and if appropriate I'd increase their quota.

*nods* I'd expect that if my upstream had any question about the quantity of outgoing messages, they'd look at the domain and see for themselves. It's pretty obvious. ;)

My concern rested with unmonitored, across-the-board limits. Again I do not wish to minimize the role of spam as I absolutely DETEST it. (I am very excited about cancelling my ISP account, when I get cable installed, so all those spammers will get bounced messages... LOL)

Admittedly the program I use allows me to send the mailings out in batches, of say 100 at a time. Don't know if this might legitimize anything as I imagine spammers have access to similar software and features. *sigh*

Appreciate the consideration... all my best.

:D Bailey

Originally posted by davidb
What do you do to stop it from going on and on.

A good way to limit it is not to offer a 10 day free trial. That's like a flashing neon sign saying "Attention Spammers! Free Access! Send as many as you can in TEN DAYS!"

You could still offer a promotion like that but make it something like "10-day trial 99 cents or $1.89 (listed this way to pleae the users who hate ".99's" -- you know who you are :) )." Something that will require you take billing and credit card information and give the spammer one more hurdle.

Also, in our TOS we reserve the right to charge spammers $500 per spam sent to cover the cost of investigation. This keeps spammers away, and if they e-mail me about it I tell them that if they don't spam they won't have a problem... they go away. :)

Hope this helps.

Thank you all for your suggestions. And yes Bravo, thank you, I now plan changing that around a little.

I am having a little trouble with that code:

chmod o-x /var/qmail/bin/qmail-queue
mv /var/qmail/bin/qmail-queue /var/qmail/bin/qmail-real-queue
install -m 2511 qmail-queue-auth /var/qmail/bin/qmail-queue

This may sound dumb, but do I run it from the command line? or what do I need to change, install -m 2511 qmail-queue-auth /var/qmail/bin/qmail-queue is really all I am confused about, thank you

Well, yes those are lines to run from the command line, but only after you've written an appropriate qmail-queue-auth program.