[23833] in Perl-Users-Digest
Perl-Users Digest, Issue: 6036 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Jan 29 21:46:40 2004
Date: Thu, 29 Jan 2004 18:41:07 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Thu, 29 Jan 2004 Volume: 10 Number: 6036
Today's topics:
perl security question <twhu@lucent.com>
Re: perl security question <usenet@morrow.me.uk>
Re: perl security question <usenet@morrow.me.uk>
Re: perl security question <dd-b@dd-b.net>
Re: perl security question <twhu@lucent.com>
Re: perl security question <usenet@morrow.me.uk>
Re: perl security question <twhu@lucent.com>
Re: perl security question <usenet@morrow.me.uk>
Re: perl security question <twhu@lucent.com>
Re: perl security question <mb@uq.net.au.invalid>
Re: perl security question <twhu@lucent.com>
Re: perl security question <Joe.Smith@inwap.com>
Re: perl security question <jwillmore@remove.adelphia.net>
Re: perl security question <twhu@lucent.com>
Re: perl security question <mb@uq.net.au.invalid>
Perl Spam Filter <hillmw@ram.lmtas.lmco.com>
Re: Perl Spam Filter <bobx@linuxmail.org>
Re: Perl Spam Filter <blank@blank.blank.com>
Re: Perl Spam Filter <trammell+usenet@hypersloth.invalid>
Re: Perl Spam Filter <jds@nospantrumpetweb.co.uk>
Re: Perl Spam Filter <dwall@fastmail.fm>
Re: Perl Spam Filter <flavell@ph.gla.ac.uk>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 23 Jan 2004 14:05:36 -0500
From: "Tulan W. Hu" <twhu@lucent.com>
Subject: perl security question
Message-Id: <burra1$qk2@netnews.proxy.lucent.com>
I have a C wraper program that has a setgid turned on.
The C wraper will call proper perl program with correct gid.
The perl program will exec another program based upon the $ARGV[0].
This works fine under perl 5.6. However, it stop working
when I recently upgraded to perl 5.8.2.
It gives me the following error
Insecure dependency in exec while running with -T switch at myprog line 26
If a user in the same group of the program, it works fine, but if a user is
not
in the the group, then it prints out the Insecure message.
Any suggestions? How can I make the exec work for a user not in the group?
c program
main() {
system("/path/prog1 /path/prog2");
}
/path/prog1:
#!/usr/bin/perl
use lib '/path/mylib';
use English;
delete @ENV{qw(IFS ENV)};
$ENV{PATH} = '/bin';
my $cmd = shift;
$EGID= $GID;
exec $cmd, 'arg1', 'arg2';
die "can't exec $cmd: $!";
/path/prog2:
#!/usr/bin/perl
print "hello $ARG[0] $ARG[1]\n";
------------------------------
Date: Fri, 23 Jan 2004 19:20:15 +0000 (UTC)
From: Ben Morrow <usenet@morrow.me.uk>
Subject: Re: perl security question
Message-Id: <burs5f$6o4$1@wisteria.csv.warwick.ac.uk>
"Tulan W. Hu" <twhu@lucent.com> wrote:
> I have a C wraper program that has a setgid turned on.
> The C wraper will call proper perl program with correct gid.
> The perl program will exec another program based upon the $ARGV[0].
Why? Why not simply exec the right program in the first place?
> This works fine under perl 5.6. However, it stop working
> when I recently upgraded to perl 5.8.2.
> It gives me the following error
> Insecure dependency in exec while running with -T switch at myprog line 26
> If a user in the same group of the program, it works fine, but if a user is
> not
> in the the group, then it prints out the Insecure message.
As this program is called from a setid C program, you should have -t
on the #! line. Then you would always get the message.
> Any suggestions? How can I make the exec work for a user not in the
> group?
Untaint $ARGV[0] with a *carefully* *crafted* regex that only lets
through programs you want to be able to exec. See perldoc perlsec, and
read *all* of it before you go any further.
> c program
> main() {
> system("/path/prog1 /path/prog2");
> }
>
> /path/prog1:
> #!/usr/bin/perl
> use lib '/path/mylib';
> use English;
Why?
> delete @ENV{qw(IFS ENV)};
> $ENV{PATH} = '/bin';
> my $cmd = shift;
> $EGID= $GID;
Another way to get rid of the taint error would be to fork and exec
manually in the C program, and do this setregid step between the
two. Then the perl program wouldn't be setid, and so wouldn't be
tainting.
> exec $cmd, 'arg1', 'arg2';
> die "can't exec $cmd: $!";
>
> /path/prog2:
> #!/usr/bin/perl
> print "hello $ARG[0] $ARG[1]\n";
Ben
--
"The Earth is degenerating these days. Bribery and corruption abound.
Children no longer mind their parents, every man wants to write a book,
and it is evident that the end of the world is fast approaching."
-Assyrian stone tablet, c.2800 BC ben@morrow.me.uk
------------------------------
Date: Fri, 23 Jan 2004 19:21:37 +0000 (UTC)
From: Ben Morrow <usenet@morrow.me.uk>
Subject: Re: perl security question
Message-Id: <burs81$6o4$2@wisteria.csv.warwick.ac.uk>
Ben Morrow <usenet@morrow.me.uk> wrote:
> As this program is called from a setid C program, you should have -t
> on the #! line. Then you would always get the message.
$*%&# fingers!
I meant -T, of course.
Ben
--
"If a book is worth reading when you are six, * ben@morrow.me.uk
it is worth reading when you are sixty." - C.S.Lewis
------------------------------
Date: Sat, 24 Jan 2004 16:37:27 -0600
From: David Dyer-Bennet <dd-b@dd-b.net>
Subject: Re: perl security question
Message-Id: <m2vfn155y0.fsf@gw.dd-b.net>
Ben Morrow <usenet@morrow.me.uk> writes:
> "Tulan W. Hu" <twhu@lucent.com> wrote:
>> I have a C wraper program that has a setgid turned on.
>> The C wraper will call proper perl program with correct gid.
>> The perl program will exec another program based upon the $ARGV[0].
>
> Why? Why not simply exec the right program in the first place?
Because you *can't*. Apache will refuse to exec a setuid/setgid
program. (So the sequence I find myself using is different from that
described by the OP; I use a non-setuid intermediate to invoke the
setuid perl script.)
--
David Dyer-Bennet, <mailto:dd-b@dd-b.net>, <http://www.dd-b.net/dd-b/>
RKBA: <http://noguns-nomoney.com> <http://www.dd-b.net/carry/>
Photos: <dd-b.lighthunters.net> Snapshots: <www.dd-b.net/dd-b/SnapshotAlbum/>
Dragaera/Steven Brust: <http://dragaera.info/>
------------------------------
Date: Mon, 26 Jan 2004 11:26:55 -0500
From: "Tulan W. Hu" <twhu@lucent.com>
Subject: Re: perl security question
Message-Id: <bv3f4g$3d9@netnews.proxy.lucent.com>
"David Dyer-Bennet" <dd-b@dd-b.net> wrote in
> Ben Morrow <usenet@morrow.me.uk> writes:
>
> > "Tulan W. Hu" <twhu@lucent.com> wrote:
> >> I have a C wraper program that has a setgid turned on.
> >> The C wraper will call proper perl program with correct gid.
> >> The perl program will exec another program based upon the $ARGV[0].
> >
> > Why? Why not simply exec the right program in the first place?
>
> Because you *can't*. Apache will refuse to exec a setuid/setgid
> program. (So the sequence I find myself using is different from that
> described by the OP; I use a non-setuid intermediate to invoke the
> setuid perl script.)
In fact, my problem does not involve Apache at all.
My c and perl programs are owned by an user, but the person, who runs
the program at the unix prompt, is not in the same group as the program
owner.
I believe perl 5.8.2 made the security tighter than perl 5.6.
I put '-t' in my program1 as Ben suggested and it still gives me the warning
but executes the program2.
------------------------------
Date: Mon, 26 Jan 2004 17:20:36 +0000 (UTC)
From: Ben Morrow <usenet@morrow.me.uk>
Subject: Re: perl security question
Message-Id: <bv3i94$7v3$1@wisteria.csv.warwick.ac.uk>
"Tulan W. Hu" <twhu@lucent.com> wrote:
> In fact, my problem does not involve Apache at all.
> My c and perl programs are owned by an user, but the person, who runs
> the program at the unix prompt, is not in the same group as the program
> owner.
> I believe perl 5.8.2 made the security tighter than perl 5.6.
>
> I put '-t' in my program1 as Ben suggested and it still gives me the warning
> but executes the program2.
Damn damn damn!!!
DO NOT USE -t IN PRODUCTION CODE.
-t was a typo. I meant to type -T. The correct answer is, as I said,
to use a regex to check that $ARGV[0] contains what you expect. Read
perldoc perlsec.
Ben
--
Joy and Woe are woven fine,
A Clothing for the Soul divine William Blake
Under every grief and pine 'Auguries of Innocence'
Runs a joy with silken twine. ben@morrow.me.uk
------------------------------
Date: Mon, 26 Jan 2004 14:54:31 -0500
From: "Tulan W. Hu" <twhu@lucent.com>
Subject: Re: perl security question
Message-Id: <bv3r9p$66l@netnews.proxy.lucent.com>
"Ben Morrow" <usenet@morrow.me.uk> wrote in
>
> "Tulan W. Hu" <twhu@lucent.com> wrote:
> > In fact, my problem does not involve Apache at all.
> > My c and perl programs are owned by an user, but the person, who runs
> > the program at the unix prompt, is not in the same group as the program
> > owner.
> > I believe perl 5.8.2 made the security tighter than perl 5.6.
> >
> > I put '-t' in my program1 as Ben suggested and it still gives me the
warning
> > but executes the program2.
>
> Damn damn damn!!!
>
> DO NOT USE -t IN PRODUCTION CODE.
>
> -t was a typo. I meant to type -T. The correct answer is, as I said,
> to use a regex to check that $ARGV[0] contains what you expect. Read
> perldoc perlsec.
>
> Ben
I knew you had a correction. I have done the checking for $ARGV[0] with -T
but it gives the same error message and not executes the program 2.
In our case, the parameter is hard coded in another program by a programmer
instead of entering by an user. I would assume it is safe.
------------------------------
Date: Mon, 26 Jan 2004 20:34:27 +0000 (UTC)
From: Ben Morrow <usenet@morrow.me.uk>
Subject: Re: perl security question
Message-Id: <bv3tkj$gv1$2@wisteria.csv.warwick.ac.uk>
"Tulan W. Hu" <twhu@lucent.com> wrote:
> "Ben Morrow" <usenet@morrow.me.uk> wrote in
> > Damn damn damn!!!
> >
> > DO NOT USE -t IN PRODUCTION CODE.
> >
> > -t was a typo. I meant to type -T. The correct answer is, as I said,
> > to use a regex to check that $ARGV[0] contains what you expect. Read
> > perldoc perlsec.
> >
> > Ben
>
> I knew you had a correction. I have done the checking for $ARGV[0] with -T
> but it gives the same error message and not executes the program 2.
> In our case, the parameter is hard coded in another program by a programmer
> instead of entering by an user. I would assume it is safe.
NO. There are very good reasons for the taint check errors; DO NOT get
rid of them.
What if someone else invokes your program? What if the first program
is compromised?
The whole point of taint checking is that you do not *assume* things
are safe, you *check* them. Have you read perldoc perlsec yet? If you
had, you would know how to untaint data, and you would have your
solution.
You still haven't answered: why do you need to do this? I strongly
suspect there is a better solution.
Ben
--
I've seen things you people wouldn't believe: attack ships on fire off the
shoulder of Orion; I've watched C-beams glitter in the darkness near the
Tannhauser Gate. All these moments will be lost, in time, like tears in rain.
Time to die. |-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-| ben@morrow.me.uk
------------------------------
Date: Mon, 26 Jan 2004 16:31:56 -0500
From: "Tulan W. Hu" <twhu@lucent.com>
Subject: Re: perl security question
Message-Id: <bv410d$7dd@netnews.proxy.lucent.com>
"Ben Morrow" <usenet@morrow.me.uk> wrote in
[snip]
>
> You still haven't answered: why do you need to do this? I strongly
> suspect there is a better solution.
Sorry I cannot give you a good answer on this question.
This just very old code we got. It works when we were using perl 5.6
but not perl 5.8.2 and no one really understands the reason behind it.
I'll re-read the security section and hopefully I'll find out the answer.
Thanks!
------------------------------
Date: Tue, 27 Jan 2004 15:50:49 +1000
From: Matthew Braid <mb@uq.net.au.invalid>
Subject: Re: perl security question
Message-Id: <bv4u7q$3gg$1@bunyip.cc.uq.edu.au>
Tulan W. Hu wrote:
> I have a C wraper program that has a setgid turned on.
> The C wraper will call proper perl program with correct gid.
> The perl program will exec another program based upon the $ARGV[0].
> This works fine under perl 5.6. However, it stop working
> when I recently upgraded to perl 5.8.2.
> It gives me the following error
> Insecure dependency in exec while running with -T switch at myprog line 26
> If a user in the same group of the program, it works fine, but if a user is
> not
> in the the group, then it prints out the Insecure message.
>
> Any suggestions? How can I make the exec work for a user not in the group?
This is a trap I fell into as well. Between 5.6 and 5.8, taint mode
became more vigorous and now no longer allows exec'ing with tainted
data. I had this problem with MIME::Lite when it exec'd for its
best-guess of sendmail.
Taint mode is on because you're running setuid/gid and perl (quite
rightly) gets antsy about what you may be about to do as someone else.
To get around it (assuming you're 100% absolutely sure what you're about
to call), you need to run the tainted data through a capturing regular
expression and use the captured data instead, eg:
my $act = $ARGV[0];
$act =~ /^(.*)\z/s; # Dangerous RE!!!
$act = $1; # $act is now untainted
exec($act); # Who knows what this is about to do
This one is dangerous though - you still have no idea what $act is, and
using it externally could lead to people running whatever they want as
the user you're setuid to.
A better way to do it is to make the RE more exact, eg:
my $act = $ARGV[0];
if ($act !~ m{^((?:/bin/ps)|(?:/bin/ls))}) {
die "Oi! That's not a valid action!";
}
$act = $1; # $act is now untainted, and you know its
# either /bin/ps or /bin/ls
exec($act);
or make a level of indirection through a dispatch table:
my $dispatch = {ls => '/bin/ls',
ps => '/bin/ps'};
my $act = $ARGV[0]; # $act is tainted, but we don't care anymore
if (not exists $dispatch->{$act}) {
die "Oi! That's not a valid action!";
}
$act = $dispatch->{$act}; # $act is now untainted
exec($act);
The last one is arguably better, since you control what the actual
external program is, and the user just gives you a flag that never hits
the underlying operating system.
Remember that you not only have to un-taint the first argument to exec,
but all the others too!
perldoc perlsec - its a wonderful thing.
MB
------------------------------
Date: Tue, 27 Jan 2004 09:02:14 -0500
From: "Tulan W. Hu" <twhu@lucent.com>
Subject: Re: perl security question
Message-Id: <bv5r19$fsr@netnews.proxy.lucent.com>
Thanks all who helped here!!!
I added an untaint function in my prog1 and
I felt much better now.
[snip]
> c program
> main() {
> system("/path/prog1 /path/prog2");
> }
>
> /path/prog1:
> #!/usr/bin/perl
> use lib '/path/mylib';
> use English;
> delete @ENV{qw(IFS ENV)};
> $ENV{PATH} = '/bin';
#> my $cmd = shift;
my $cmd = untaint($ARGV[0]);
> $EGID= $GID;
> exec $cmd, 'arg1', 'arg2';
> die "can't exec $cmd: $!";
sub untaint {
my ($param) = @_;
# do my checking and make sure it is expected.
$param =~ s/%([\dA-Fa-f][\dA-Fa-f])/pack ("C", hex ($1))/eg;
return $param;
}
>
> /path/prog2:
> #!/usr/bin/perl
> print "hello $ARG[0] $ARG[1]\n";
------------------------------
Date: Wed, 28 Jan 2004 08:01:33 GMT
From: Joe Smith <Joe.Smith@inwap.com>
Subject: Re: perl security question
Message-Id: <x%JRb.168482$I06.1678904@attbi_s01>
Tulan W. Hu wrote:
> Thanks all who helped here!!!
> I added an untaint function in my prog1 and
> I felt much better now.
Um, your untaint() function does not actually
untaint its argument.
> sub untaint {
> my ($param) = @_;
> # do my checking and make sure it is expected.
> $param =~ s/%([\dA-Fa-f][\dA-Fa-f])/pack ("C", hex ($1))/eg;
> return $param;
> }
Try running that with untaint("rm%20-rf%20.");
It's time for you to go back to the drawing board.
-Joe
--
I love my TiVo - http://www.inwap.com/u/joe/tivo/
------------------------------
Date: Wed, 28 Jan 2004 09:15:48 -0500
From: James Willmore <jwillmore@remove.adelphia.net>
Subject: Re: perl security question
Message-Id: <pan.2004.01.28.14.15.46.319593@remove.adelphia.net>
On Tue, 27 Jan 2004 09:02:14 -0500, Tulan W. Hu wrote:
> Thanks all who helped here!!!
> I added an untaint function in my prog1 and I felt much better now.
>
> [snip]
>> c program
>> main() {
>> system("/path/prog1 /path/prog2");
>> }
>>
>> /path/prog1:
>> #!/usr/bin/perl
>> use lib '/path/mylib';
>> use English;
>> delete @ENV{qw(IFS ENV)};
>> $ENV{PATH} = '/bin';
> #> my $cmd = shift;
> my $cmd = untaint($ARGV[0]);
>> $EGID= $GID;
>> exec $cmd, 'arg1', 'arg2';
>> die "can't exec $cmd: $!";
> sub untaint {
> my ($param) = @_;
> # do my checking and make sure it is expected. $param =~
> s/%([\dA-Fa-f][\dA-Fa-f])/pack ("C", hex ($1))/eg; return $param;
> }
>>
>> /path/prog2:
>> #!/usr/bin/perl
>> print "hello $ARG[0] $ARG[1]\n";
To learn how to properly untaint values for CGI scripts to use, visit:
http://www.w3.org/Security/Faq/www-security-faq.html
And, you can also see CERT's blurb on removing metacharacters from user
supplied data at: http://www.cert.org/tech_tips/cgi_metacharacters.html
--
Jim
Copyright notice: all code written by the author in this post is
released under the GPL. http://www.gnu.org/licenses/gpl.txt
for more information.
a fortune quote ...
Even if you do learn to speak correct English, whom are you going
to speak it to? -- Clarence Darrow
------------------------------
Date: Wed, 28 Jan 2004 10:34:22 -0500
From: "Tulan W. Hu" <twhu@lucent.com>
Subject: Re: perl security question
Message-Id: <bv8kq6$1no@netnews.proxy.lucent.com>
"Joe Smith" <Joe.Smith@inwap.com> wrote...
[snip]
>
> Try running that with untaint("rm%20-rf%20.");
> It's time for you to go back to the drawing board.
Thanks for the warning.
I picked Mathew Braid's suggestion and put in the untaint function.
I'll read more about the security issues from James Willmore suggested URLs.
You guys are great and picked all the details.
------------------------------
Date: Thu, 29 Jan 2004 12:20:30 +1000
From: Matthew Braid <mb@uq.net.au.invalid>
Subject: Re: perl security question
Message-Id: <bv9qlf$vki$1@bunyip.cc.uq.edu.au>
Tulan W. Hu wrote:
> "Joe Smith" <Joe.Smith@inwap.com> wrote...
> [snip]
>
>>Try running that with untaint("rm%20-rf%20.");
>>It's time for you to go back to the drawing board.
>
> Thanks for the warning.
> I picked Mathew Braid's suggestion and put in the untaint function.
> I'll read more about the security issues from James Willmore suggested URLs.
>
> You guys are great and picked all the details.
>
>
BTW - just noticed there is a security bug in one of my examples:
# my $act = $ARGV[0];
# if ($act !~ m{^((?:/bin/ps)|(?:/bin/ls))}) {
^^
# die "Oi! That's not a valid action!";
# }
# $act = $1; # $act is now untainted, and you know its
# # either /bin/ps or /bin/ls
# exec($act);
I forgot to anchor the end of the RE with a \z, so anything that
_starts_ with /bin/ps or /bin/ls will get though. Whoops :)
MB
------------------------------
Date: Mon, 26 Jan 2004 13:56:57 -0600
From: Michael Hill <hillmw@ram.lmtas.lmco.com>
Subject: Perl Spam Filter
Message-Id: <40157109.C150F595@ram.lmtas.lmco.com>
I was wondering if there is someone who knows a good perl spam filter.
Mike
------------------------------
Date: Mon, 26 Jan 2004 15:22:44 -0500
From: "Robert" <bobx@linuxmail.org>
Subject: Re: Perl Spam Filter
Message-Id: <ofadnXZgD-yI6ojd4p2dnA@adelphia.com>
"Michael Hill" <hillmw@ram.lmtas.lmco.com> wrote in message
news:40157109.C150F595@ram.lmtas.lmco.com...
> I was wondering if there is someone who knows a good perl spam filter.
>
> Mike
>
Look up "Popfile" on GOOGLE.
------------------------------
Date: Mon, 26 Jan 2004 15:21:23 -0500
From: "Scot" <blank@blank.blank.com>
Subject: Re: Perl Spam Filter
Message-Id: <bv3srs$8c9@library2.airnews.net>
spamassassin
"Michael Hill" <hillmw@ram.lmtas.lmco.com> wrote in message
news:40157109.C150F595@ram.lmtas.lmco.com...
> I was wondering if there is someone who knows a good perl spam filter.
>
> Mike
>
------------------------------
Date: Mon, 26 Jan 2004 20:33:10 +0000 (UTC)
From: "John J. Trammell" <trammell+usenet@hypersloth.invalid>
Subject: Re: Perl Spam Filter
Message-Id: <slrnc1auc6.i3u.trammell+usenet@hypersloth.el-swifto.com.invalid>
On Mon, 26 Jan 2004 13:56:57 -0600, Michael Hill wrote:
> I was wondering if there is someone who knows a good
> perl spam filter.
>
That's funny. Most of my spam is for v1agr4 and p3nis
3nl@rg3ment, not Perl.
------------------------------
Date: Mon, 26 Jan 2004 20:12:38 -0000
From: "Julia deSilva" <jds@nospantrumpetweb.co.uk>
Subject: Re: Perl Spam Filter
Message-Id: <IteRb.5$lz3.2@news-binary.blueyonder.co.uk>
"Michael Hill" <hillmw@ram.lmtas.lmco.com> wrote in message
news:40157109.C150F595@ram.lmtas.lmco.com...
> I was wondering if there is someone who knows a good perl spam filter.
>
> Mike
Depends what you want it to do. Is this a Perl question
or is Mailwasher a good suggestion ?
J
------------------------------
Date: Mon, 26 Jan 2004 21:55:43 -0000
From: "David K. Wall" <dwall@fastmail.fm>
Subject: Re: Perl Spam Filter
Message-Id: <Xns947CAC3577F35dkwwashere@216.168.3.30>
John J. Trammell <trammell+usenet@hypersloth.invalid> wrote:
> On Mon, 26 Jan 2004 13:56:57 -0600, Michael Hill wrote:
>> I was wondering if there is someone who knows a good
>> perl spam filter.
>>
>
> That's funny. Most of my spam is for v1agr4 and p3nis
> 3nl@rg3ment, not Perl.
Do you get tired after only a few hours of programming? No more! Code with
enthusiam! Order P3rlagra now! Good for those all-night hacking sessions!
Don't be "just another" Perl hacker, be a REAL Perl hacker!*
As a bonus, get the Golfing Companion! Shrink that verbose program by 200%!
That's right, 200%! No need for Perl obfuscators or crufty "compilers" to
hide your valuable Perl code -- the Golfing Companion will make your code
so tight (yeah, baby) even YOU can't read it!
* (small print: side effects may include speech alterations such as use of
"G'day" or "Crikey" and odd pronunciations of other words.)
inharmonious dadaist slighting brownie enjoyment whittle gentrifying strips
scalinesses chlordanes obduracy disable provocativenesses interlocked
infinitely excavated lobby groupie figments wildflowers overexposes
pompously calve tremolos obdurate enthronements quantifier centrism
strikeouts bushwhack aspect swifts splicing brunt sacs articulating
advisedly necromancers eyedroppers retardant codifiers honorer readout
distension washerwoman metre wove shirkers hairsbreadths reclassification
cooperations obtrusivenesses aquifers squished demographers nationality
remittances antitoxins enact communicators replicated friedcakes centre
longstanding scats sapient carding pastern carvings uniting brokenhearted
reminiscing devoutest papaya blackening inefficiency stoppled fabricators
theaters title duo paralleled phalanxes individuality remitting epitomizing
ditto eagle gyration fastback sulfas farrow backdating upends eighties
stumbled bacilli birds lagoon fonts
------------------------------
Date: Mon, 26 Jan 2004 22:08:13 +0000
From: "Alan J. Flavell" <flavell@ph.gla.ac.uk>
Subject: Re: Perl Spam Filter
Message-Id: <Pine.LNX.4.53.0401262200110.31392@ppepc56.ph.gla.ac.uk>
On Mon, 26 Jan 2004, Michael Hill wrote:
> I was wondering if there is someone who knows a good perl spam filter.
We get excellent results with spamassassin, but the question of what
language it's written in isn't exactly our top priority, since it
would likely become a maintenance overhead if we kept meddling with
the actual code.
(The MTA - in our case exim - actually communicates with a permanently
running spamassassin daemon, spamd).
http://spamassassin.org/
But unless you're more interested in the Perl code than in getting the
functionality, I'd respectfully suggest you're off-topic here, and
would be better off on a forum where mail admins hang out.
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V10 Issue 6036
***************************************
