Does anyone have any resources on building a mail relay that would limit
the amount of email a single user or ip address can relay over a given
time period?
I have a spam/virus problem that is getting out of hand.
Adi
<quote who="Adi Linden">
Does anyone have any resources on building a mail relay that would limit
the amount of email a single user or ip address can relay over a given
time period?
relayd for qmail
http://dizzy.roedu.net/relayd/
I'm sure something exists for Sendmail's milter interface.
Might start looking at: http://www.mimedefang.org/ (aka http://www.canit.ca/)
-davidu
http://monkey.org/~jose/software/vthrottle/
It allows you to say you will only take 1 email from an IP in a given
period of time, and you can whitelist and more.
What I'm looking for that would be even better is vthrottle added onto,
or something else that I just haven't found yet, that would have a sliding
window X and say that within X we will only take Y emails, and block if
its above that. Have X and Y be a generic setting and then the ability to
change them for a given netblock, so that AOL and other large providers do
not get hit by it.
But as it is, libmilter vthrottle looks like the best there is right now.
Adi Linden wrote:
Does anyone have any resources on building a mail relay that would limit the amount of email a single user or ip address can relay over a given time period?
I have a spam/virus problem that is getting out of hand.
Adi
Has anyone tested sendmail 8.13alpha, in specific its rate-limiting?
Postfix's anvil feature may meet the need. Its available in the CVS
snapshots. Some basic documentation is at
Does anyone have any resources on building a mail relay that would limit
the amount of email a single user or ip address can relay over a given
time period?I have a spam/virus problem that is getting out of hand.
Depending on your MTA poison of choice there's lots out there. Personally
I use exim in most of my deployments, and it has a very nice progressive
rate limiting feature (ie accept two MAIL commands with no delay, at 0.5
seconds for the third, scaling at a rate a 1.05 times per message until 5
minute delay per message is reached) that is fully configurable.
(http://www.exim.org/exim-html-4.30/doc/html/spec_14.html#IX1351)
Exim, as well as almost every other MTA out there has support for inline
virus scanning, which may help with your problem as well.
-Scott
Thank you for all the information. It gives me a few choices to maul over.
Right now the single largest issue are compromised PCs that are abused for
sending SPAM and also send viruses. I am seriously considering the idea of
forcing all smtp traffic through a mail relay of some sort.
The newest viruses are smart enough to find mail servers that are
available to relay through on the network. So it is not the final answer
to just have a relay. But at the very least it will provide a single point
to deal with the problem.
Is there a way do transparently redirect smtp traffic to a server
elsewhere on the network using Cisco gear? It would be much easier to
implement this solution if smtp traffic is transparently sent through the
dedicated box rather than 'cutting off' all users until they manually
reconfigure their clients to use the new mail relay.
Adi
Quoting Adi Linden <adil@adis.on.ca>:
Is there a way do transparently redirect smtp traffic to a server
elsewhere on the network using Cisco gear? It would be much easier to
implement this solution if smtp traffic is transparently sent through the
dedicated box rather than 'cutting off' all users until they manually
reconfigure their clients to use the new mail relay.Adi
Will the Cisco WCCP protocol do what is necessary in this case?
On Thu, 25 Mar 2004 13:25:51 CST, Adi Linden <adil@adis.on.ca> said:
Is there a way do transparently redirect smtp traffic to a server
elsewhere on the network using Cisco gear? It would be much easier to
implement this solution if smtp traffic is transparently sent through the
dedicated box rather than 'cutting off' all users until they manually
reconfigure their clients to use the new mail relay.
On the other hand, it's probably more effective to find some way of making the
Cisco gear block outbound 25 from abusive machines. Transparently redirecting
the traffic is evil unless you plan to take all responsibility for relaying the
mail (including mail that has MAIL FROM/RCPT TO that you may not wish to
relay).
Everybody who's ever been a road warrior and trapped behind a hotel or ISP that
gratuitously snarfs up port 25 and then mangles your mail knows what I mean...
Everybody who's ever been a road warrior and trapped behind a hotel or ISP that
gratuitously snarfs up port 25 and then mangles your mail knows what I mean...
That's why network guys set up port 587 SMTP support, or ...even worse... authenticated port-80 SMTP relays on an otherwise idle machine in your NOC. Since its not for general consumption it doesn't need to be easy or automatic as long as it works.
I have been to hotels that wouldn't allow SSH or telnet, and only allowed port-80.. hence the creation of monstrous kludges on top of the only open port.
YMMV,
Deepak Jain
AiNET
On the other hand, it's probably more effective to find some way of making the
Cisco gear block outbound 25 from abusive machines. Transparently redirecting
the traffic is evil unless you plan to take all responsibility for relaying the
mail (including mail that has MAIL FROM/RCPT TO that you may not wish to
relay).
Right now I am blocking all network access for ip addresses I receive
believeable abuse reports for. The big problem is that it is a manual
process that does not start until a PC has already sent a massive amount
of abusive mail. After all, it does take time to read and act upon abuse
reports. By forcing smtp through a specific server at least some proactive
measures are possible such as throttling abusive behaviour.
Adi
Adi Linden wrote:
Right now I am blocking all network access for ip addresses I receive
believeable abuse reports for. The big problem is that it is a manual process that does not start until a PC has already sent a massive amount of abusive mail. After all, it does take time to read and act upon abuse reports. By forcing smtp through a specific server at least some proactive measures are possible such as throttling abusive behaviour.
When you get bored fighting the fire with a leaking bucket of water, technology exists that automates detection, redirection, posting information to the end users and eventually re-enabling the subscribers without any manual intervention. Makes days significantly less dull, but I might be biased here 
Pete
Forcing it through a server doesn't automagically add the ability to throttle
abusive behavior. It's merely the obvious sledgehammer fix.
Now consider a router that's instrumented to collect flow data, feeding a
real-time system that throttles the port if something abusive happens. You get
the same benefits of not having to read and act on abuse reports, plus you
don't break non-abusive uses of the network.
(And yes, we consider that a primary tool - we got lots of "your user has Witty"
e-mails, and *every single one* we already knew about because we'd pulled the
flow data and done the obvious things....)
That's why network guys set up port 587 SMTP support, or ...even
worse... authenticated port-80 SMTP relays on an otherwise idle machine
in your NOC. Since its not for general consumption it doesn't need to be
easy or automatic as long as it works.
So you're saying that since the privileged few can work around it, it's
OK to do it to your customers who maybe aren't so privileged
I have been to hotels that wouldn't allow SSH or telnet, and only
allowed port-80.. hence the creation of monstrous kludges on top of the
only open port.
And here I thought the substrate protocol for the Internet was IPv[46], not
HTTP. 
When you get bored fighting the fire with a leaking bucket of water,
technology exists that automates detection, redirection, posting
information to the end users and eventually re-enabling the subscribers
without any manual intervention. Makes days significantly less dull, but
I might be biased here
Where?
Adi
Forcing it through a server doesn't automagically add the ability to throttle
abusive behavior. It's merely the obvious sledgehammer fix.
It's a means to deal with smtp traffic.
Now consider a router that's instrumented to collect flow data, feeding a
real-time system that throttles the port if something abusive happens. You get
the same benefits of not having to read and act on abuse reports, plus you
don't break non-abusive uses of the network.
Where is something like this documented and explained?
Adi
Inbound also. The spammers have been using triangular routing
for a while.
(They dial in someplace, get an IP, and use a broadband connection
to send packets with a forged source address of that dialup IP.)
Ray,
Take a look at IOS server load balancing. You create a virtual server
with your public IP address and bind 1 or more real servers to this
"serverfarm".
The nice thing about IOS SLB is that it is part of the IOS image in native
mode on the 65xx and the 72xx series. It runs on a couple of other
platforms but you would need to search CCO to find out which ones.
Scott C. McGrath
If your customer-facing routers/switches are able to generate flow statistics,
it's a Small Matter Of Programming to have something catch said data and do the
analysis. You might need some semi-studly backend systems, but the basic idea
isn't any more complicated than a 'cut | sort | uniq -c | sort -nr | head'
pipeline.
As a data point, some 200 of our boxes got nailed by Witty, and the flow data
for udp/4000 for 3/19 and 3/20 was 18GB. Of course, since essentially each
packet ended up being a separate flow, this was a very worst case scenario (one
box alone did 3M flows in 1 hour, but it was on a 100Mbit port). Expect much
lower numbers of flows from even the most ambitious cablemodem or DSL based
spambot.