OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: Re: idea: content filtering
From: Wietse Venema (wietseporcupine.org)
Date: Wed May 10 2000 - 08:41:33 CDT

Michael Tokarev:
> Wietse Venema wrote:
> >
> > I had an idea today for making it easy to do content filtering in
> > Postfix.
> >
> []
> >
> > postfix-userspostfix.org -> postfix-userspostfix.org.SANITIZE
> >
> > all mail for *.SANITIZE is routed to an external command (using
> []
>
> All this sounds good. Just some more thought.
>
> Is it required so that _all_ mail should be routed this way?

As I proposed, the .SANITIZE is would be under control by a regexp.
If desirable, mail for Postmaster or fax can be exempted.

> Some days ago there was a proposal about routing throuth a viri/content
> checking for only some of mails, particularily with attachtments...
> Maybe the recipient_mapping can be combined with some sort of header_checks,
> so that non-interesting (from virii checking view) mail will not be routed
> to checking engine? But, again, this (sort of header_checks) should be applied
> to contents, not just to headers...

I consider it a bad idea to only inspect only mail that is MIME crippled.
It is safer to inspect all mail.

> About contents checking. If the system supports mmap, this is
>a bit trivial.
> We can just mmap() queue file and apply regexps for it. And this
>method seemed
> to be fast enouth.

Sorry, but yes/no reply is too limited. There must be a way to
TRANSFORM mail so it can be delivered without causing immediate
harm.

> This is what I can propose... :)

It is considered rude to send out emails with lines > 80. From
here on I will truncate your text.

> In the queue file, add some flag indicating that this mess
>age is in "checked" state
> (like with recipient_mapping's .SANITIZE). All of the inj

Sotty, but one bit is too limited. I want the ability to apply
different filters for different conditions. Hence the use of a
symbolic name, rather a fixed number of bits.

>ection mechanisms (smtpd,
> sendmail etc) will leave this flag off. And, say, qmgr, i
>f it sees such a flag, will
> call some transport to sanitise message (that can "send" m
>essage out-of-postfix, as in
> Wietse's proposal), and mark it as "checked". After this,
> mail goes as usual.

You describe how mail leaves Postfix and enters the inspector, but
not how the result of inspection is delivered. If the context
inspector TRANSFORMS mail, then the result has to be passed from
inspector to Postfix. For that I proposed to use one of the existing
mail submission mechanisms. Thus, we have

  Postfix d.a. -> inspector -> Postfix mail submission (transform
  filter)

If the inspector doesn't like the mail, it terminates with an exit
status that causes mail to be bounced.

If the inspector agrees with the mail, submit the mail to Postfix,
possibly after transforming it.

Any external interfaces involved with context inspection shall be
usable for purposes other than content inspection.

        Wietse