Re: [SAGE] ISP class egress anti-spam filtering

["Neil Neely" <neil@frii.com>]

Some great thoughts have been shared already on the subject, I'd like to
paraphrase and combine these:

* Egress Filtering is a poor choice of term for political reasons
(suggestions anyone? I'll try out 'inbound vs outbound filtering' for now)

* Any solution has to be conscious of the business case.  A solution that
incurs massive costs for little to no tangible gain is senseless and no
one will deploy it.

* Outright Blocking of outbound port 25 is effective, but disruptive and
unlikely to be a popular solution applied retroactively.

* Commonly utilized inbound filtering approaches may not be appropriate
for outbound filtering.  In particular the concept of quarantine might be
a poor choice for outbound filtering.

* should be easy for an administrator to trial out (like spamassassin was
easy for an admin to put on their own procmail prior to full deploy)
[Just to emphasis that - low barrier to entry was what I was getting at
earlier, using spamassassin itself is not at all what I meant]

I believe this problem can further be subdivided into three different
problems:

#1) Filtering on the ISP's outbound mailserver.  This would be analyzing
mail going through the officially legitimate channel that customers should
be using.

#2) Filtering outbound mail from client software.  This would represent
filtering mail out of say firefox, outlook, malware, etc.

#3) Filtering outbound mail from server software.  This would represent
filtering mail sent from sendmail, postfix, exchange, etc.

For the moment I'd like to try to simplify this discussion by focusing on
#2 and to a lesser degree #3.  I'm saying this based on the reality that
malware is responsible for a lot of the problem, and I'm more interested
in choking that off than anything else.

I believe it is important for us to look at server software as well - any
solution that is suggested that makes it impossible to run a server out of
a given network is going to be hugely unpopular.

Focusing in on the client filtering portion of this, I believe the
transparent smtp proxy concept has a lot of appeal.  Being able to
intercede at the SMTP layer seems like the best possible solution to
ensure that the client gets immediate feedback, and avoids the rather
complicated problem of sorting out any kind of quarantine system.

Spending some time on Google I came across this:
smtp-gated
http://smtp-proxy.klolik.org/

It can hook into a lot of different tools, including content inspectors
like spamassassin, but I'm really only interested in one of the features:

4. Can block messages if AUTH is not used (optionally passing if AUTH is
not supported by MSA)

This is the only real feature of this that I think we would need.  The
idea being:  No SMTP traffic unless you ran smtp auth first.  This would
nuke the ability for clients to send directly to remote servers they
didn't have accounts on - but not completely block them.  Requiring the
use of SMTP AUTH to use remote mail servers doesn't feel to me like it is
asking too much.  Introducing it likely would generate some support costs,
but with an easy work around this *might* be more acceptable.

If this software supported whitelisting source IP's (for customers of the
ISP running servers) and destination IP's (for exempting some remote hosts
that you want to be more permissive with for whatever reason) I think this
might meet the criteria we are all looking for.  This doesn't solve all
problems that could ever come up, but it is sounding good to me right now.

Has anyone ever tried doing anything like this?  Anyone ever used
smtp-gated?   Any other recommended transparent smtp proxy programs that
would be better choices?  Any huge holes in my reasoning that I am missing
out on?



Neil Neely - Senior Systems Engineer
FRII
neil@frii.com