[Esd-l] Special rules
Christian Parigger
cparigge at utsi.edu
Wed Nov 27 10:15:01 PST 2002
Hi,
I would think that an addition in your procmailrc (or filterrc) below the
line defining POISONED_EXECUTABLES should work (and maybe "re-defining
"MANGLE_EXTENSIONS" is also desired similarly).
You would create personx-files from poisoned-files; the example below is
inferred from http://www.impsec.org/email-tools/sanitizer-configuration.html
C.P.
:0
* ^To: personx at yourdomain.ext
{
POISONED_EXECUTABLES=/etc/procmail/personx-files
}
On Wed, 27 Nov 2002 15:31:42 +0200, Herbert Nkhoma wrote
> Hi,
>
> I have only one client who would like to get double or more
> extension files, the rest are fine with the current arrangement
> (they are stripped)
>
> Is it possible for this one client to use a stripped file different
> from the rest of the other users.
>
> Or what other ways can I help this client?
>
> Herbert
> ----- Original Message -----
> From: "Christian Parigger" <cparigge at utsi.edu>
> To: "Jack Gryn" <jgryn at aepi.dhs.org>; "Karl Dunn" <k.l.dunn at ieee.org>
> Cc: "Email Security Discussion List" <Esd-l at spconnect.com>
> Sent: Friday, November 22, 2002 8:22 AM
> Subject: Re: [Esd-l] Re: Procmail/Sanitizer Question
>
> > Jack,
> >
> > Yes, the filterrc solution by Karl is working just great,
> > thanks to the fantastic details and comments by Karl,
> > and I agree with your comment patching up directly
> > (I was running 8.12.5 on a RH8.0 for this).
> >
> > Also, some time in the past I used MIMEDefang and
> > it worked very well, including simultaneously using
> > MIMEDefang and John's procmail. RH8.0 out-of-box
> > with sendmail 8.12.5 and implementing procmail is very
> > quick and convenient (including the filterrc if you wish).
> >
> > I revisited MIMEDefang tonite, followed the MIMEDefang
> > HOWTO (excellent) and tested the .forward issue
> > with mimedefang-2.26, sendmail 8.12.6 and RH 8.0.
> > It does take care of the .forward issue, for example,
> > by designing all *.doc files as bad --- and MIMEDefang
> > successfully removes the file and includes a message that
> > the *.doc file was removed in the forwarded e-mal.
> > However, installing 8.12.6 with "milter" and the perl scripts
> > and startup/shutdown scripts may not be everybodies cake
> > (although if you have a spare few hours I think you can do
> > this as well).
> >
> > I personally like John's procmail (with possibly the filterrc extension)
> > due to the outstanding track record that I enjoy. MIMEDefang
> > is highly configurable with all the perl, including things like
> > spamassassin. And wishful thinking includes the hope that
> > for me John's procmail will be fantastic forever and forever...
> >
> > Chris
> >
> >
> >
> > ----- Original Message -----
> > From: "Jack Gryn" <jgryn at aepi.dhs.org>
> > To: "Karl Dunn" <k.l.dunn at ieee.org>
> > Cc: "Christian Parigger" <cgparigger at mindspring.com>; "Email Security
> Discussion List" <Esd-l at spconnect.com>
> > Sent: Tuesday, November 19, 2002 6:52 PM
> > Subject: [Esd-l] Re: Procmail/Sanitizer Question
> >
> >
> > Hello,.
> >
> > I seem to have gotten it working properly. I appreciate your time
> > and effort.
> >
> > Everything seems to work. It is a little slow processing the mailing
> > lists as some of my lists have close to 100 addresses in them.
> >
> > There are a few minor issues.
> >
> > a) My version of redhat.mc was different than yours, so as a result, the
> > patch didn't work. I patched sendmail.cf directly for now to get it up
> > and running.
> >
> > b) I set my filterrc file to be basically equivalent to my old procmailrc
> > file + a few extra lines for delivery.
> > (old procmailrc file +)
> > NL="
> > "
> > LOGABSTRACT=no
> >
> > :0 # re-send the message
> > ! -oi -f "$@"
> >
> > In the original portion of the filterrc, Idefine SECURITY_QUARANTINE to a
> > file (/var/spool/mail/security), so I can keep quarantined messages
> > somewhere just incase it was unnecessarily marked as quarantined (it
> > happens occationally if someone names a file as one on the poisoned list).
> >
> > For some reason procmail seems to corrupt this file when I get a
> > 'quarantined' e-mail. The first FROM line of the header seems to be
> > missing which causes pine to see the mailbox as corrupted. Previously,
> > the mailbox would not be corrupted.
> >
> > c) This is probably unreleated but when I try to send myself a file with a
> > 'poisoned' file name to test; I get the error message
> >
> > " NOTICE: Envelope sender domain (mydomainname) not supported by Received:
> > path. Suppressing sender notification."
> >
> > I'm assuming its a DNS issue since my IP doesn't reverse lookup to my
> > actual hostname.
> >
> > Anyways, I appreciate your time and effort.
> >
> > I'll let you know if there are any more issues over the next couple of
> > days in testing.
> >
> > Let me know if you have any thoughts about the issues I mentioned
> >
> > Thanks
> >
> > Jack
> >
> >
> > On Tue, 19 Nov 2002, Karl L. Dunn wrote:
> >
> > > Jack:
> > >
> > > I set up two machines to test a solution for you: a PC running FreeBSD
> > > 4.3 with sendmail 8.11.3 (different OS, nearly the same sendmail as for
> > > you), and a DEC Multia/UDB (Alpha 166MHz) running RedHat Linux 6.0 alpha
> > > with sendmail 8.9.3 (similar OS but older sendmail than for you). Both
> > > have perl 5.005-03.
> > >
> > > There is a third PC on the net, running FreeBSD 4.3, that I usually use
> as
> > > a DNS server, mail gateway, Samba server, and a firewall. I co-opted it
> > > to set up a different net and domain, with routing set up on all three
> > > machines, so I had a test bed. There was no mail gateway; the first PC
> > > and the Multia had direct access to the "internet" simulated by the
> > > co-opted firewall PC.
> > >
> > > I sent messages from a user to itself, user to another user, user to a
> > > different domain, different domain to a local user, and tried out
> > > .forwards and non-local aliases. It all seems to work as you desire.
> > > Underscore on "seems" -- I'm fairly confident but not 100% certain. I
> > > did not try a mailing list, nor very many cases.
> > >
> > > Mail should go through the /etc/procmailrcs/filterrc script no matter
> > > where it's going or where it comes from. It may go through it more than
> > > once -- for example, if local user A mails to local user B, it goes
> > > through filterrc twice: once when sendmail gets it from A for
> > > transmission, and once when another instance of sendmail hands it to the
> > > local delivery agent to give it to B. Notice that procmail is doing the
> > > filtering, because of the rules added to ruleset 98. In your case, the
> > > local delivery is also done by procmail. These are two different
> > > definitions for mailers in sendmail.cf. The local delivery instance of
> > > procmail does not do any filtering (although it does, apparently, for
> > > your current setup; see below). Notice further that sendmail in this
> > > example runs four times; once when it gets A's message and sends it
> > > through filterrc because of ruleset 98, once because the lines at the
> end
> > > of filterrc send it back through sendmail where ruleset 98 undoes the
> name
> > > tag it attached the first time and transmits the message, and a similar
> > > two invocations for delivering to B.
> > >
> > > I have a residual mystery: mail coming into the Multia from elsewhere,
> > > either the local domain or another one, goes through the filter
> (procmail)
> > > twice (sendmail four times). That does not happen for the PC. I don't
> > > know why this happens. If it doesn't happen to you, I'll forget about
> it.
> > > (I didn't forget about the magic file, so that's not the explanation --
> > > read on).
> > >
> > > Your current situation seems to me to be that you have put the filter
> > > script (named procmailrc) in the magic place, probably /etc for RedHat.
> > > It's /usr/local/etc for FreeBSD. If you do that, the local mailer
> > > instance of procmail (and any other procmail for that matter) will use
> it,
> > > with its ownership; see the man page on procmail. Therefore, the
> filters
> > > work if and only if the mail is to be delivered locally (or some user
> > > invokes it explicitly) -- otherwise procmail does not run. What you
> > > wanted, as I understand you, is for procmail to filter ALL mail. To do
> > > that, sendmail has to be told explicitly to use a different mailer
> > > definition (also procmail); that is what the P class definition and the
> > > additional rules for ruleset 98 are for. You then can and must get rid
> of
> > > the /etc/procmailrc file; rename it at least -- otherwise every instance
> > > of procmail will run that too, causing you a lot of confusion.
> > >
> > > Be careful editing sendmail.cf -- tabs and spaces mean different things.
> > > That's why I sent you patch files.
> > >
> > > Since I don't have RH 7.2, and I don't have the exact sendmail you have,
> > > my test sendmail.cf files are NOT what you have, although I took care to
> > > make them functionally the same. I did follow the procedures below,
> just
> > > to make sure they work, at least on my own RH 6.0 system.
> > >
> > > Please let us know if this works or not, and what tweaks you needed to
> > > apply, as I'll bet you will.
> > >
> > > BTW: I apologize for possibly making this far too detailed. I think
> it's
> > > safe to assume that you know most of this.
> > >
> > > - - - - -
> > >
> > > With respect to your question about loading due to mailing lists:
> > >
> > > You should have no load problem for just a few users. I had a similar
> > > arrangement on an internal server, and on redundant gateways, for the
> > > corporate mail system where I worked until I retired about a year ago.
> A
> > > Sun IPX did the entire job for about 150 users until I replaced it in
> > > early 2001. That Sun benches out about like a 486/25 PC, and it had
> about
> > > 64MB of memory -- not much horsepower. It handled on average about 100
> > > messages per minute during working hours, sometimes approaching 100% CPU
> > > load when the sanitizer was scanning a big Microsoft attachment for
> > > macros. You probably don't have that slow or small a machine, so I
> don't
> > > think you should worry about processing a message for each of a lot of
> > > recipients on a list.
> > >
> > > If you wind up someday with more than just a few accounts, you can
> afford
> > > a gateway, and you should probably set one up anyway just to have a good
> > > firewall (I did it for the company with FreeBSD's IPFW and TIS's proxy
> > > software). The gateway can process incoming mail to users and to lists
> the
> > > same way, and the list alias can spread things out on the host you have
> > > now, without filtering.
> > >
> > > - - - - -
> > >
> > > These procedures work on RH 6.0. There WILL be differences for other
> > > versions of Linux, even for RedHat Linux. Adjust as necessary.
> > >
> > > To build the new sendmail.cf using the m4 method:
> > >
> > > cd $HOME/work Get somewhere safe
> > >
> > > Unpack the tarball. (e.g, gtar zxvf no-gate.tgz)
> > > You should have two patch files, and my filterrc:
> > >
> > > -rw-r--r-- kdunn/kdunn 1244 2002-11-18 20:24 cf.patch
> > > -rw-r--r-- kdunn/kdunn 984 2002-11-18 20:29 mc.patch
> > > -rw-r--r-- kdunn/kdunn 1116 1999-09-06 11:49 filterrc
> > >
> > > (You should set up your own filterrc -- this one is just my test.)
> > >
> > > cp -p /usr/lib/sendmail-cf/cf/redhat.mc . Copy the generic mc file
> > > patch < mc.patch Make new -.mc (same name)
> > > su - root Become superuser
> > > cd /usr/lib/sendmail-cf/cf Get into the build
> directory
> > > (If this doesn't work, rpm -ivh the sendmail-cf rpm from the RH CD)
> > > cp -p ~kdunn/work/redhat.mc jg.mc Get the new -.mc with a
> new name
> > > m4 jg.mc > /etc/jg.cf Create the new -.cf
> > > cd /etc Go where you put it
> > > diff sendmail.cf jg.cf Check it
> > > mv sendmail.cf sm_cf_sma Save the old sendmail.cf
> > > mv jg.cf sendmail.cf Install the new
> sendmail.cf
> > >
> > > If you want to fix sendmail.cf directly (NOT recommended):
> > >
> > > cd $HOME/work
> > > patch < cf.patch Create new -.cf from the
> old one
> > > su - root Become superuser
> > > cd /etc Go where you put it
> > > mv sendmail.cf sm_cf_sma Save the old sendmail.cf
> > > cp ~yourself/work/sendmail.cf . Install the new -.cf
> > >
> > > Then:
> > >
> > > chown root.root sendmail.cf Set ownership
> > > chmod 644 sendmail.cf Set privs
> > > /etc/rc.d/init.d/sendmail stop Stop (kill) sendmail
> > > /etc/rc.d/init.d/sendmail start Start a new one
> > > cd /var/log Get into the log directory
> > > touch procmail.log Create procmail.log
> > > chmod 666 procmail.log Set loose privs on it
> > >
> > > ls -Flag /var/log/procmail.log Check it
> > >
> > > -rw-rw-rw- 1 root root 746 Nov 19 11:55
> /var/log/procmail.log
> > >
> > > ls -FlagR /etc/procmail* Check the procmail files
> > >
> > > /etc/procmail:
> > > total 5
> > > drwxr-sr-x 2 root wheel 1024 May 27 16:38 ./
> > > drwxr-xr-x 33 root root 3072 Nov 19 11:35 ../
> > > -rw-r--r-- 1 root wheel 581 May 27 16:38 poisoned
> > >
> > > /etc/procmailrcs:
> > > total 59
> > > drwxr-sr-x 2 root wheel 1024 May 26 23:19 ./
> > > drwxr-xr-x 33 root root 3072 Nov 19 11:35 ../
> > > -rw-r--r-- 1 root wheel 1116 Sep 6 1999 filterrc
> > > -rw-r--r-- 1 root wheel 52688 May 26 23:19
> html-trap.procmail
> > >
> > > (There should be NO /etc/procmailrc file -- you don't want one)
> > >
> > > Note carefully the ownerships and privs.
> > >
> > > Test carefully!
> > _______________________________________________
> > Esd-l mailing list
> > Esd-l at spconnect.com
> > http://www.spconnect.com/mailman/listinfo/esd-l
> > _______________________________________________
> > Esd-l mailing list
> > Esd-l at spconnect.com
> > http://www.spconnect.com/mailman/listinfo/esd-l
> _______________________________________________
> Esd-l mailing list
> Esd-l at spconnect.com
> http://www.spconnect.com/mailman/listinfo/esd-l
More information about the esd-l
mailing list