[Mimedefang] OT: control internal spam

[James Ebright]

SMTP Auth is well supported now days, uses port 587 (and 483 if you use TLS
and outlook) and would be one way I would approach the issue.. of course.. if
you have a user with a valid username/pass or certificate (depends on flavor
of auth you prefer) then they will be able to send out the spam in either
case.. just harder for them to claim it was a virus or zombied box if they had
to authenticate to do it. Not to mention you can remove the user IP space from
relay so they cannot use the gateway for external mail at all unless they
authenticate first.

Any rate limiting you place on an IP (bandwidth or messages per min or recip
per message) will just give you a false sense of security and possible catch
some legitimate mailing lists as well. The abuser can simply vary the rate or
amount of bulk (or even send them a single at a time) in order to get around
this limit.

I would say this is best handled with a strict email use policy (TOS) and
educating your users on what happens if they are caught sending out spam (e.g.
we charge our hourly rate for "clean up" fees for any time we spend running
down spam, dealing with third parties, etc to our former customer if they are
caught maliciously sending spam). Nothing to prevent you from turning over a
complete archive of evidence to the local authorities for use under the canned
spam act as well (yeah, I know that may be a toothless threat, but students
may not know that). Couple that with the monitoring you are already doing and
you should be fine, 2k messages is not alot at all after all (a couple of
minutes worth on a broadband connection) so you did catch them fairly quickly.

Jim

On Tue, 3 May 2005 17:05:42 -0500 (CDT), -ray wrote
> All,
> 
> We block port 25 at the firewall so all outgoing mail has to go out 
> our gateway.  Occasionally a student will figure out they can make a 
> few $$$ by relaying spam.  It doesn't happen often, but happened 
> today and they managed to sneak out 2000 messages before we noticed.
> 
> Any ideas on how to combat this?  Obviously we have to allow SMTP 
> for internal legit clients on our network.  Is SMTP AUTH the answer? 
> Or pop before SMTP? (currently not using these).  Some kind of rate 
> limiting per IP?  Just looking for any ideas...


--
EsisNet.com Webmail Client