Hi, On Wed, 12 Feb 2003 10:05:11 -0500 Theo Van Dinter <[EMAIL PROTECTED]> wrote:
> On Tue, Feb 11, 2003 at 11:46:16PM -0600, Bob Apthorpe wrote: > > - We can still apply user-specific checks (something we can't do when > > analyzing during the SMTP DATA phase.) > > > > The devil (and all his host of little minions) is in the details... :) > > > > Thoughts? Flames? Donuts? > > I haven't been paying attention to this thread so far, but you can't > do user-specific filtering via MTA. Unless you do it at delivery, but > then why do it in the MTA... It's all a part of 1 message with multiple > deliveries, it has to be filtered the same for all. Here's a more concrete example: The MTA receives a message destined for a local alias. The alias points to 5 real users. When the MTA receives the message, SA is called and it runs DCC, Razor2, and Pyzor checks and DNSBL checks, stuffs the results in a database and stamps the record key in the header. The alias is expanded and the message is delivered to five mailboxes. During the delivery process, SA is run again, the results of the previous checks are retrieved from the database, the remainder of the rules are run including any custom user rules and a final score is calculated and stamped into the body or header. Benefits: We run expensive tests once per inbound message, not five times (once for each delivered message.) But say network tests are too expensive to run on the MTA. Say we run all the computationally-cheap non-network, non-user-adjustable tests on the MTA, and calculate an initial generic score. If that score is above a high threshhold (say 15), reject the mail, otherwise store the results of tests in the database as before and discard the initial generic score. Final delivery works as described as before but the particular group of rules applied changes. Benefits: We can reject the mail at the SMTP DATA phase and still apply user preferences. We can defer expensive tests. One of the best things about SpamAssassin is that it can be run at the MTA (amavis/MIMEDefang/milter) level, at the MDA (procmail) level, and at the MUA (SAproxy/pop3proxy) level. As the effectiveness of SA increases, so do concerns about performance. By processing at several points in the message delivery path, we can shift load to machines with more capacity and solve the dilemma of applying user preferences while still being able to reject abusive traffic before it enters the mail system. -- Bob ------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _______________________________________________ Spamassassin-talk mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
