Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Message-ID: <42C42F13.2080407@cornell.edu>
Date: Thu, 30 Jun 2005 13:42:43 -0400
From: Paul A Houle <ph18@cornell.edu>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
MIME-Version: 1.0
To: dev@httpd.apache.org
Subject: Re: mod_smtpd project planning
References: <42C1DB49.5030603@force-elite.com>
  <66b2553bcc594a0b4530b3bb71c6e455@gbiv.com>  <42C29DA1.6090506@holsman.net>
  <b5b17bce77139717213891b7a137cd3f@gbiv.com>  <42C37EFA.2040005@mit.edu>
  <jbm.20050630003324.892d2561@alkaid.pc9>  <42C40A28.8060502@cornell.edu>
  <42C413FD.7060609@mit.edu> <jbm.20050630113755.a71a74fb@alkaid.pc9>
In-Reply-To: <jbm.20050630113755.a71a74fb@alkaid.pc9>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Jem Berkes wrote:

>This is the problem encountered by many spam filters, as to be most 
>effective they really need to be _involved_ in the SMTP transaction and not 
>just stage 2, after receipt happens. Think greylisting as an example.
>
>  
>
    You read this?

http://www.acme.com/mail_filtering/

    One thing that's critical isn't just having access to information 
from early stages of mail processing,  but being able to intervene at 
early stages in the processing so to avoid the CPU and bandwidth waste 
at advanced stages.  This particularly matters during a computer virus 
outbreak:  I remember hitting on many of Jeff's solutions when a mail 
server I managed was getting hammered by an incredible volume of 
viruses,  and I wrote scripts that picked up bad addresses from the 
virus filter output and put them into the software firewall.