Procmail vs Perl.
Sam
Hash: SHA1
In article <1efbf1y.171gvyotw70ytN%to...@svanstrom.com>,
to...@svanstrom.com (Tony L. Svanstrom) writes:
> A simple question: Why would I want to learn how to use procmail when I
> already know Perl, wouldn't it be easier, as well as potentially a lot
> more powerful, to simply use Perl for the mailfiltering?
And how do you propose to actually use Perl to filter your incoming mail?
> I've printed about 50-60 pages of documents related to procmail, and at
> a first look there seems to me as if there are no real advantages to
> using Procmail vs a Perl-based solution. Clearly there must be something
> that I miss, but what?
Yes: your mail server runs procmail to deliver your mail. It doesn't run
Perl to do that. procmail applies the filtering instructions, and, if
instructed to do so, delivers the mail to your system mailbox.
Running Perl instead of procmail will accomplish absolutely nothing, except
losing your mail, unless you write the actual code to deliver your mail to
your system mailbox, after any filtering takes place. To do that, you need
to know where your system mailbox is, and the correct procedure to deliver
mail there. Simply appending the message may not always work, in most
cases there are some low-level locking procedures that need to take place.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: http://www.geocities.com/SiliconValley/Peaks/5799/GPGKEY.txt
iD8DBQE5ltL3+3BFaxHnGY0RAkckAKCzJQ/ZMREHXYp6LnYpfFBkWrZalgCfTLtE
zc7XvA097PNYCt/QaWaxnJ4=
=3chd
-----END PGP SIGNATURE-----
Timo Salmi
Tony L. Svanstrom <to...@svanstrom.com> wrote:
:A simple question: Why would I want to learn how to use procmail when I
:already know Perl, wouldn't it be easier, as well as potentially a lot
:more powerful, to simply use Perl for the mailfiltering?
Dear Tony,
If you feel comfortable with Perl, and really can achieve an
effective email filtering with it, then there is no reason
whatsoever why you would want to learn procmail. One should use the
tools that one is most comfortable with. However, I must say that
you really are an admirably skilful Perl programmer if you can
easily make Perl scripts achieve all what procmail can.
Procmail is a tool that has developed in particular for email
filtering. Thus it is very powerful and an extremely useful tool for
that task. But that is not a compelling reason to choose it if you
already have a tool that you know, like, and can dextrously use for
the task.
Personally I use procmail and like it, because it gets my filtering
done very well. But I am not an advocate of any particular tool like
procmail, so I do not have an answer to you why use it unless you
want and need to by your own volition.
All the best, Timo
--
Prof. Timo Salmi ftp & http://garbo.uwasa.fi/ archives 193.166.120.5
Department of Accounting and Business Finance ; University of Vaasa
mailto:t...@uwasa.fi <http://www.uwasa.fi/~ts/> ; FIN-65101, Finland
Timo's procmail tips at http://www.uwasa.fi/~ts/info/proctips.html
chris ulrich
Tony L. Svanstrom <to...@svanstrom.com> wrote:
%%already know Perl, wouldn't it be easier, as well as potentially a lot
%%more powerful, to simply use Perl for the mailfiltering?
%%
%%I've printed about 50-60 pages of documents related to procmail, and at
%%a first look there seems to me as if there are no real advantages to
%%using Procmail vs a Perl-based solution. Clearly there must be something
%%that I miss, but what?
%%
%% /Tony
That's not a bad idea.
I'd probably punt on the actual delivery by passing the message on to
mail.local or procmail, but procmail as a mail filter seems rather ugly.
But before doing any of that, you might want to look at "maildrop"
which is the local delivey agent from the courier mail package. It's
filter language, compaired to procmail, is a whole lot less full of magic
and weirdness. It's at http://download.sourceforge.net/courier/
After all, where it's silly to learn something complex when you can
use something complex that you already know, it is better still to use
something simple that does exactly what you want without having to
learn anything very complex at all (especially if that knowledge will
be otherwise useless beyond the initial problem set).
chris
Alan J. Flavell
> Ah, now we're getting to the interesting stuff... Exactly what is it
> that Procmail is doing that I can't do with Perl, when it comes to
> writing to the mailbox?
It knows a whole lot about different kinds of mailbox and different
locking strategies. If you toss out procmail, you'd have to re-invent
those. Well, at least you'd have to re-invent the ones you need - and
if/when you move to a different environment you'd likely have to do it
over again.
(So why not use procmail to pipe the stuff into your Perl script, and
get the best of both?)
cheers
jason
>Sam <s...@email-scan.com> wrote:
>
>> In article <1efbf1y.171gvyotw70ytN%to...@svanstrom.com>,
>> to...@svanstrom.com (Tony L. Svanstrom) writes:
>>
I don't seem to have your original post here - so excuse this thread
breaker
your question was asked and answered by Simon Cozens in the latest TPJ
.. he created Mail::Audit which is on CPAN .. well worth a look
--
jason -- elep...@squirrelgroup.com --
Abigail
in <URL:news:MPG.1401c6cc2a636da19896ad@localhost>:
?? Tony L. Svanstrom wrote ..
?? >Sam <s...@email-scan.com> wrote:
?? >
?? >> In article <1efbf1y.171gvyotw70ytN%to...@svanstrom.com>,
?? >> to...@svanstrom.com (Tony L. Svanstrom) writes:
?? >>
?? >> > A simple question: Why would I want to learn how to use procmail when I
?? >> > already know Perl, wouldn't it be easier, as well as potentially a lot
?? >> > more powerful, to simply use Perl for the mailfiltering?
??
?? I don't seem to have your original post here - so excuse this thread
?? breaker
??
?? your question was asked and answered by Simon Cozens in the latest TPJ
?? .. he created Mail::Audit which is on CPAN .. well worth a look
I looked, I read its limitations, I decided to stay with procmail.
I do have a Perl program to modify the .procmailrc for me though.
Abigail
--
sub A::TIESCALAR{bless\my$x=>A};package B;@q[0..3]=qw/Hacker Perl
Another Just/;use overload'""'=>sub{pop @q};sub A::FETCH{bless\my
$y=>B}; tie my $shoe => qq 'A';print "$shoe $shoe $shoe $shoe\n";
Jürgen Exner
news:1efbmse.1s7p8t2171w2glN%to...@svanstrom.com...
> Ah, now we're getting to the interesting stuff... Exactly what is it
> that Procmail is doing that I can't do with Perl, when it comes to
> writing to the mailbox?
Nothing. Of course you could re-implement procmail in Perl,
The only question is why would you want to?
jue
jason
>jason (elep...@squirrelgroup.com) wrote on MMDXXXIX September MCMXCIII
>in <URL:news:MPG.1401c6cc2a636da19896ad@localhost>:
>?? Tony L. Svanstrom wrote ..
>?? >Sam <s...@email-scan.com> wrote:
>?? >
>?? >> In article <1efbf1y.171gvyotw70ytN%to...@svanstrom.com>,
>?? >> to...@svanstrom.com (Tony L. Svanstrom) writes:
>?? >>
>?? >> > A simple question: Why would I want to learn how to use procmail when I
>?? >> > already know Perl, wouldn't it be easier, as well as potentially a lot
>?? >> > more powerful, to simply use Perl for the mailfiltering?
>??
>?? I don't seem to have your original post here - so excuse this thread
>?? breaker
>??
>?? your question was asked and answered by Simon Cozens in the latest TPJ
>?? .. he created Mail::Audit which is on CPAN .. well worth a look
>
>
>I looked, I read its limitations, I decided to stay with procmail.
me too .. but my mail filtering requirements are very simple (and I've
never really had a problem with the procmail syntax)
>I do have a Perl program to modify the .procmailrc for me though.
I'll bet you do
Timo Salmi
Tony L. Svanstrom <to...@svanstrom.com> wrote:
:Timo Salmi <t...@UWasa.Fi> wrote:
:So... the way I see it the only benefits from using procmail, vs Perl,
:is that it allows you to write to the mailbox in a simpler way. Using
Quite! That's exactly it. Partly repeating what I said earlier, I do
not press for using procmail if you can achieve the same things with
Perl and already know it intimately and/or like it. To write a good
filtering system one needs a scipting language on top of procmail to
complement it, anyway. Using procmail alone is a bit cumbersome for
really complicated tasks. At the very least the ~/.procmail.rc soon
grows too long to be easily managed.
Personally, I use a combination of procmail and Bourne shell
scripts. In my case I do not use Bourne shell alone (as I take you
now use Perl), but indeed a combination of the two where I let
procmail select (some) of the messages for a more elaborate
handling, such as autoresponses and advice to Garbo archives upload
submitters, or most importantly, to run my email password system.
But many of the simpler situations I let procmail handle without any
additional scripts.
An example of a combination of procmail and Bourne shell scripting
for the interested is to be found e.g. at
Foiling Spam with an Email Password System
http://www.uwasa.fi/~ts/info/spamfoil.html
BTW, you mentioned the program "filter" somewhere. I have been told
that it is inadvisable to use that program at all, since it is
supposed to have serious security holes. So much so that e.g. at my
location the program has been deleted from public usage.
el...@iii.org.tw
> So... the way I see it the only benefits from using procmail, vs Perl,
> is that it allows you to write to the mailbox in a simpler way. Using
> procmail allows the scripts to be much smaller.
[snip]
Tony,
Maybe you should take a look at devlier:
http://deliver.sourceforge.net/
It seems to be a better fit if you want to write scripts.
Chih-Cherng Chin
el...@iii.org.tw
Alex Graf
I think Mail::Header groks rfc822 messages
On Tue, 15 Aug 2000 00:00:23 +0200, to...@svanstrom.com (Tony L.
Svanstrom) wrote:
>I've now started working on a Perl-based solution; so far I've only got
>a few lines that split up the headers and separate them from the body,
Mark Thomas
> understand why procmail is better; and I hope that the ones reading
> this, and that love procmail, can tell me why.
Sorry I got into this thread a bit late. I think you should check out
PerlMx. It seems to me that this Perl solution one-ups procmail. Here's the
first few paragraphs from the description:
PerlMx is a mail filter engine designed to operate under sendmail. Beginning
with v8.10, sendmail provides scriptable hooks into all stages of an e-mail
transaction, allowing custom actions on any aspect of the transaction,
including the content of the message itself. PerlMx allows these hooks to be
written in Perl, making for rapid prototyping, debugging, and deployment of
custom e-mail filtering solutions.
The functionality provided by PerlMx is not to be confused with traditional
backend e-mail delivery processing, done with tools such as procmail after a
message has been accepted for delivery by sendmail. In contrast, a PerlMx
filter operates at the level of the incoming SMTP connection, which means it
has complete control over factors such as whether a connection should be
accepted, and whether the content received during the connection should be
altered before delivery. For example, this allows sendmail to efficiently
deny connections based on various factors such as the sender, recipient, or
other content in the body of the message. Since such processing happens as
soon as the content is seen by sendmail, it improves the overall performance
of the mail server.
PerlMx is designed to provide an efficient, scalable, and customizable
framework of solutions for the entire range of e-mail filtering tasks. These
include:
Mail Archiving: selectively log e-mail traffic based on arbitrary criteria
Volume Accounting: keep track of e-mail volumes to generate statistics
Custom Routing: redirect mail to third parties based on sender, recipient or
other external parameters
Control: implement your own heuristics for weeding out "spam" e-mail
Keyword Scanning: add custom actions based on keywords in e-mail
Content Rewriting: add new headers or change existing content of to incoming
messages
--snip--
PerlMx is free (currently in beta) from ActiveState:
http://www.activestate.com/Products/PerlMx
--
Mark Thomas
ne...@markthomas.org
Uri Guttman
TLS> A simple question: Why would I want to learn how to use procmail
TLS> when I already know Perl, wouldn't it be easier, as well as
TLS> potentially a lot more powerful, to simply use Perl for the
TLS> mailfiltering?
checkout Mail::Audit which does what you are looking for. i am about to
start using it. it has some limitations but it lets you write filters
and select the mailboxes for each incoming letter.
uri
--
Uri Guttman --------- u...@sysarch.com ---------- http://www.sysarch.com
SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting
The Perl Books Page ----------- http://www.sysarch.com/cgi-bin/perl_books
The Best Search Engine on the Net ---------- http://www.northernlight.com
Eli the Bearded
Because procmail regexps can be painful?
Because procmail syntax can cause you to tear your hair out?
Because procmail source can cause you to tear your hair out?
Because procmail itself can't edit messages?
Because procmail itself can't handle databases? (The procmail
package does come with formail, that can keep track of message
IDs.)
I've done some complex stuff with procmail, hundreds of
recipes totalling thousands of lines, and not all just
:0:
* condition
file
stuff, but scoring, detection of duplicate messages by multiple
criteria (not just message-ID), small mailing lists, mail-to-news
gateways, in-line decoding of 8-bit messages, pre-extraction of
attachments, to name a few things.
In many cases doing these things has required external programs,
but could be implemented all within perl.
Perl doesn't come with all the safety nets of procmail, though.
They could be written, but perl does make it easier to screw
up this sort of thing, due to it's increased power. File locking
in procmail is as simple as :0: verus :0, file locking in perl
requires actual code. If something fails, procmail can usually
save the day and manage to get your mail into $DEFAULT or
$ORGMAIL as a last resort.
Some sort of perl within procmail would be nice. I tried
doing that once, but perl's tainting checking does not like
embeded perl interpreters in suid programs, which is a
standard way to install procmail.
Elijah
------
you might also want to do it as part of the perl power tools...
Eli the Bearded
In comp.lang.perl.misc, Alex Graf <alex.graf@.....ec.gc.ca> wrote:
> On Tue, 15 Aug 2000 00:00:23 +0200, to...@svanstrom.com (Tony L.
> Svanstrom) wrote:
> >I've now started working on a Perl-based solution; so far I've only got
> >a few lines that split up the headers and separate them from the body,
> I think Mail::Header groks rfc822 messages
perl -MMail::Header
Can't locate Mail/Header.pm in @INC (@INC contains: /home/username/perl5lib
/usr/lib/perl5/5.6.0/i686-linux-thread-multi /usr/lib/perl5/5.6.0
/usr/lib/perl5/site_perl/5.6.0/i686-linux-thread-multi
/usr/lib/perl5/site_perl/5.6.0 /usr/lib/perl5/site_perl/5.005
/usr/lib/perl5/site_perl .).
BEGIN failed--compilation aborted.
Hope you didn't lose your incoming mail.
Elijah
------
you could eval it, but don't forget even strict.pm could be missing
Mike Stok
Maybe you need to install the Mail::Header module...
[mike@ratdog mike]$ perl -MMail::Header -e'print "OK\n"'
OK
I believe it's part of the MailTools module/bundle which can be found on CPAN.
Hope this helps,
Mike
--
mi...@stok.co.uk | The "`Stok' disclaimers" apply.
http://www.stok.co.uk/~mike/ |
GPG PGP Key 1024D/059913DA | Fingerprint 0570 71CD 6790 7C28 3D60
st...@colltech.com (CT - work) | 75D2 9EC4 C1C0 0599 13DA
mark_...@my-deja.com
mark_...@my-deja.com
Eli the Bearded
> Eli the Bearded <eli...@workspot.net> wrote:
> >> >I've now started working on a Perl-based solution; so far I've only got
> >> >a few lines that split up the headers and separate them from the body,
> >> I think Mail::Header groks rfc822 messages
> >perl -MMail::Header
> >Can't locate Mail/Header.pm in @INC (@INC contains: /home/username/perl5lib
> >Hope you didn't lose your incoming mail.
> Maybe you need to install the Mail::Header module...
My point was that if your script is dependent on modules, then
you must be careful that mail does not get lost because the
module is not installed. Eg, because it is a compiled module
and you just upgraded your perl and didn't reinstall all the
modules.
Anyway, I'm pretty sure that Mail::Header mangles headers too
much for my tastes in mail filtering. I'd like to know if
some mail had a 'Subject' or 'SUBJECT' line, sometimes. It
seems to be able to keep them internally with a particular
case, but there does not seem to be a way to get the extract
string used for the header name. (The whole list of headers,
yes, bot not a particular one.)
I also see that the parser of Mail::Header does not handle the
example A.3.3 from RFC822, sticking rather strictly to the
BNF definitions. (RFC822 is a bit contradictory at times, but
good software should be forgiving.)
Anyway, a simple header grep can be done quite simply in perl.
See hgrep in the scripts section of CPAN. (http://www.cpan.org/
for the comp.mail.misc folks.)
Elijah
------
doesn't like the data abstractions modules make sometimes
Yiorgos Adamopoulos
>I've now started working on a Perl-based solution; so far I've only got
>a few lines that split up the headers and separate them from the body,
>I'm doing my best to keep it nice to the system.
Take care that whatever line is inputed in your script is not evaluated
like a valid Perl expression and then executed. That could lead to nasty
things happening from your account.
--adamo
Uri Guttman
TLS> Tony L. Svanstrom <to...@svanstrom.com> wrote:
>> A simple question: Why would I want to learn how to use procmail when I
>> already know Perl, wouldn't it be easier, as well as potentially a lot
>> more powerful, to simply use Perl for the mailfiltering?
TLS> I've now started working on a Perl-based solution; so far I've
TLS> only got a few lines that split up the headers and separate them
TLS> from the body, but I'm getting there. Altough I haven't focused
TLS> too much on it so far I'm doing my best to keep it nice to the
TLS> system.
too late.
check out Mail::Procmail and Mail::Audit. both do what you want with
different methods (one stole ideas from the other). i have checked them
out and am starting to use the procmail one. both are very easy to use
and allow you to check with perl code which place to deliver the
message. no need to use plain procmail again. now we can have readable
perl code splitting our mail.
Mail::Procmail comes with a good example file which handles mailing
lists, and many other mail types including spam.
Johan Vromans
> Tony L. Svanstrom <to...@svanstrom.com> wrote:
>
> > A simple question: Why would I want to learn how to use procmail when I
> > already know Perl, wouldn't it be easier, as well as potentially a lot
> > more powerful, to simply use Perl for the mailfiltering?
>
> Thank you all that answered.
>
> I've now started working on a Perl-based solution; so far I've only got
> a few lines that split up the headers and separate them from the body,
> but I'm getting there. Altough I haven't focused too much on it so far
> I'm doing my best to keep it nice to the system.
Check Mail::Procmail on CPAN.
Slightly different is Mail::Audit, also on CPAN.
-- Johan