Re: Re[2]: Syntax question: smtp-policy.spam

[Matti Aarnio <mea@nic.funet.fi>]

On Fri, Jun 14, 2002 at 11:37:25AM +0200, Marek Kowal wrote:
> > With the recent exposion of spam and virus traffic, I became 
> > concerned about content filtering.  But I am wandering if extra 
> > fork()/exec() for every message is practical...  
> 
> Exactly. This opens the computer to DoS attack - just send many letters and
> you've got fork-bomb. Even very good linuxes act slow above 50 forks()/sec.

  If you look at how the contentfilter interface is written at ZMailer,
  non-forking is a big thing in it.   All this presuming that incoming
  messages are not coming in separate connections...

  A multithreaded smtp input engine in which single process instance
  handles lots of incoming sessions might alleviate some of the problems.
  If you look at the smtpserver code, it has quite a lot of things in
  "SS" state variable structure, and very little in scattered global
  state variables.   Adding multiplexed access to permanently running
  router server process(es), and content filter(s) (pools of resources
  if single instances are bottlenecks.)

  However things won't be "low technology approach", once threads step
  into the picture..

  (And once the smtpserver is threaded, scheduler will actually get more
   benefits from the same treatment.)

> > We currently process well over a million messages per day.  
> > Ideally, content filter might be built in smtpserver binary, with 
> > filtering rules dynamically reloadable the same way as current policy
> database.
> 
> I doubt it should be in the binary - it will grow big and maintenance will
> become real burden. The best way - I believe - is to create separate
> program, which listens on the socket for incoming letters, parses them, and
> then answers (in unerstandable way) - what should be done to the letter. it
> might also return reprocessed letter (i.e. with viruses removed). once the
> interface is well documented, anyone can write his/her own content filter,
> the zmailer just contacts it.

  Definitely a binary engine, which understands various things about
  the message -- like MIME structure, decodes BASE64 encoded parts
  in the analysis, etc.

  Having smart ways to define rules for downloading & internal compilation
  would be bonus.  (E.g. RE patterns downloaded, and on-demand optimized
  for re-interpretation, think of PERL RE's "o" option.)

> In this way the program gets separated from smtpserver, you do not have
> forks, and you can develop filter in any language (probably starting off
> with perl, but ending up in pure C for sites requiring bigger efficiency). 

  Quite so.  Bottleneck issues need to be handled, though.

> Also, there is question, where the filter should be installed - in the
> smtp-server (better response to still-connected SMTP client, but bigger
> openess to DoS attack (smtpserver works on-line!), or in router (off-line,
> but in case of problems no way to contact SMTP client).

  I begun to use the contentfilter myself to showe a middle finger on
  HTML email senders.  It does incidentially also cut down about 90+%
  of incoming spams and viruses...

  At one system I have a reply like:

  return "-1 550 5.7.1 The message contains HTML, therefore we consider".
         "it SPAM.  Send pure TEXT/PLAIN if you are not a spammer.";

> Cheers,
> Marek.
-- 
/Matti Aarnio	<mea@nic.funet.fi>
-
To unsubscribe from this list: send the line "unsubscribe zmailer" in
the body of a message to majordomo@nic.funet.fi