[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [SAGE] ISP class egress anti-spam filtering
On 11/16/07, Neil Neely wrote:
> First I should ask: Are there any free open source ISP class egress
> anti-spam filtering solutions out there that anyone has ever utilized?
> I've seen some links to a handful of vendors doing this in general,
> but haven't looked too closely.
At AOL, our answer was to transparently proxy all outbound port 25
traffic from our clients through a set of dedicated servers, and then
we actively asked all the known blacklist operators to include the IP
addresses of these machines on their blacklists.
So far as I know, this pretty much completely eliminated the
complaints about AOL customers that were directly spamming sites out
on the Internet, because the Abuse Team at AOL is pretty good at
shutting down real AOL customers who abuse other sites, and this
eliminated their alternatives.
Of course, this caused certain other classes of problems -- lots of
people I know of had AOL accounts that they could use as remote
access around the world, and then submit their legitimate e-mail
(possibly via their "home" server) while travelling abroad. When we
shut down outbound port 25, these people were completely shut out
unless they could switch to an alternative port -- like the
Submission protocol on port 587.
When I was working at Skynet SA/NV (the largest ISP in Belgium, with
about a million customers as of the time I left), our answer was to
use certain blacklists on our outbound mail servers, and we did not
auto-whitelist our own customers on these machines.
This meant that if an external operator of a particular blacklist got
a spam report regarding one of our customers, they could add that IP
address to their blacklist and we would honor that on our outbound
mail servers, even though the IP address in question is one of our
own customers.
> I believe this problem space is relatively unexplored, and I would suggest
> to this group of people that this is the next frontier on the anti-spam
> war that we should collectively work towards.
Agreed.
> A free open source relatively easy to deploy tool named spamassassin
> came along a number of years ago and launched a revolution in ingress
> spam filtering technologies, and we now have many, many wonderful tools
> at our disposal that help reduce the flood of bad coming into our
> networks.
SpamAssassin is one tool. It's a hammer.
When all you have is a hammer, everything looks like a nail.
I believe that there are other things out there that are not nails,
and we should not be abusing the one tool we've found so far to treat
them as nails.
> What I would love to see is a similar revolution occur with
> egress filtering.
I think we need to be careful when choosing terms. When you use the
term "egress filtering", I believe that many ISPs will think of just
the sorts of things that have been extensively talked about at NANOG,
and we won't have any more success with that concept than they have.
You don't want to take a term that is already known and thought
poorly of, and then apply that to yourself out of ignorance.
> The problem space is really quite different from ingress filtering,
Agreed.
> In ingress filtering you know the destination, so you
> can simply quarantine those dubious messages for users to review - in
> egress filtering you don't necessarily have a clue who the sender is
> (which is a core part of the problem obviously). What is the best way
> to deal with this? There are many other challenges relating to
> egress filtering, and we collectively desperately need better answers
> to these problems.
Well, we presumably do know where the message is coming from. They
may not be the original sender, but they presumably are our customer
and we know who they are.
> The theory I am operating on is that egress filtering could follow the
> same path as ingress filtering - the introduction of a free open source
> solution that was relatively easy to deploy started a revolution so that
> now everyone does it. If it were easy for ISP operators to truly police
> their users than we would do it. If high quality egress filtering
> were ubiquitous and relatively inexpensive it would become far easier to
> hold ISP's accountable if they weren't doing this.
At the network layer, the folks on NANOG have put together some
pretty good tools to make this fairly easy, and yet the vast, vast
majority of ISPs don't pay any attention what so ever to network
layer egress filtering. So, just putting the toolsets out there
isn't enough.
You've got to have the motivation to use the tools, too. This might
be a positive "carrot" motivation, or a negative "stick" motivation,
or both.
At the higher layers, I agree that this is a different class of
problems, and while there are some pieces of information we don't
have because the direction has changed, I think we also need to take
advantage of the fact that there are other pieces of information we
do have which we do not have for ingress, and we can use this to our
advantage.
What those kinds of tools might look like, I have no idea. I'll be
interested to see what we can find.
--
Brad Knowles <brad@shub-internet.org>
LinkedIn Profile: <http://tinyurl.com/y8kpxu>