Mailing-List: contact users-help@spamassassin.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (nike.apache.org: local policy)
Date: Sat, 20 Aug 2011 21:55:08 +0200
From: Patrick Ben Koetter <p@state-of-mind.de>
To: users@spamassassin.apache.org
Subject: Re: Theories on blocking OUTGOING spam
Message-ID: <20110820195508.GB2211@state-of-mind.de>
References: <4E4AE8F8.4060500@junkemailfilter.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <4E4AE8F8.4060500@junkemailfilter.com>

* Marc Perkel <support@junkemailfilter.com>:
> Just sharing some ideas on blocking outbound spam. Maybe these ideas
> will make it to the big freemail companies because most of the spam
> that manages to get through my filters comes from AOL, Gmail, Yahoo,
> and Hotmail.
> 
> I've found outbound spam filtering to be very different than inbound
> filtering. And I've been reasonably successful in stopping spam that

ACK

# Throwing in an advocatus diaboli in the next lines. Basically I do agree
# with most what you say

> I'm filtering for other people's outgoing servers. Here's the core
> of how I do it.
> 
> First - spammers never send spam slowly. So if the account is
> sending email slowly then I don't have to look at it. So it just
> passes.

Spammers will adopt to that. Imagine they infect the complete network and all
infected machines do a distributed spam attack each sending only a few to keep
beneath the threshold but over all sending a lot. I wouldn't rely on that - at
least in the long run.


> When email is coming fast from an account I start tracking the
> number of bad recipients and if the number of bad recipients is high
> it's probably spam.

Or its bulk mail with bad addresses ...


> I also have restrictions on valid domains the from has to match, I
> look for URIBLs, high SA scores, etc.
> 
> Just curious what others do to detect outgoing spam.

- We keep lists of valid senders. Others are not allowed to send unless we can
  verify (sender verification) them immediately.
- We require humans to use submission instead of smtp
- We run pretty tight policies on web hosting machines and standalone (null
  mailer) servers

Generally we look at the SMTP session only and avoid inspecting anything at
content level for several reasons:

- German laws forbid looking at content without local senders consent.
  That holds true even (!) if the mail system is at risk because the spam load
  gets close to DOSing the machine or if your machines start to get
  blacklisted. I am not sure if judges will actually sentence someone if they
  claimed system risk the reason why they inspected the content, but there is
  no precedent yet and I'd rather not spend my money finding out ...
- Looking at content is computationally expensive

When we look at the SMTP session we MUST NOT log anything that leads back to
the real person or lets us track the person down. If we log we use hashes to
destroy a trackable connection.

We tend to think the client sends spam if

- the client sends an abnormal number of messages within a timeframe
- the clients sends to a wide variety of recipients

We put message in quarantine and notify the sender. The sender may release the
messages - a self-service a spambot can't do itself.

> I use Exim for the MTA because it has the power to do the tricks I
> need done.

We use Postfix. It gets the job done too.

p@rick

-- 
state of mind ()

http://www.state-of-mind.de

Franziskanerstraße 15      Telefon +49 89 3090 4664
81669 München              Telefax +49 89 3090 4666

Amtsgericht München        Partnerschaftsregister PR 563