[Esd-l] Special rules

Herbert Nkhoma hnkhoma at clcom.net
Wed Nov 27 05:31:00 PST 2002


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



More information about the esd-l mailing list