Very Computer

I don't know what to do to perform these tasks.
Can the features be obtained by creative use of the sendmail-daemon ?
Or should some daemon look in the mail-boxes every five minutes to see if new
mail have arrived that needs to be processed ?

Some basic hints on this this newbie question would be very appreciated

Hardware: SPARC5, Soft: Solaris 2.4 ( I think it's a 'standard' sendmaild )

--
Soeren Holstebroe - Panum institute, DK

: I don't know what to do to perform these tasks.
: Can the features be obtained by creative use of the sendmail-daemon ?
: Or should some daemon look in the mail-boxes every five minutes to see if new
: mail have arrived that needs to be processed ?

: Some basic hints on this this newbie question would be very appreciated

: Hardware: SPARC5, Soft: Solaris 2.4 ( I think it's a 'standard' sendmaild )

One relatively painless way to do this is with aliases. For example,
have user eric make a .forward file that points to ericprint. Then, in
your /etc/aliases file add a line that goes:

ericprint:  "| lpr (options)"

where (options), of course, are whatever options to lpr you need, e.g.
to specify Eric's printer. Note that basically you're aliasing an
email address to a pipe. Similarly, for user joe who wants his mail
processed by some shell script (or Perl, or C, or whatever), joe
forwards his mail to joesmailscript, which is then aliased as

joesmailscript:  "| /usr/joe/mailscript"

The mailing list package Majordomo (actually just a set of Perl
scripts) uses this method to process messages to mailing list addresses
automatically. You can find out more about Majordomo by looking at
http://www.greatcircle.com/majordomo/.

Good luck!

                                                --Clay
--


Schools of Medicine & Nursing     | http://maddog.fammed.wisc.edu/~helberg
University of Wisconsin-Madison   | Speaking only on my own behalf....

   I need some hints on how to do some automatic processing on incoming mail.
   Ex. I want all emails to user eric to be printed on the laserprinter in his
   office as they arrive, and then mark the emails as 'read'.
   Or I want all incoming mails to user some_mail_daemon to be 'tossed' to a
   program that handles the content of the mail and delete the mail from
   some_mail_daemon's mailbox.
[...]

Sounds like you need procmail!  I use this system and highly recommend
it...  Here's the README:

----------------------
Procmail & formail mail processing package.
Copyright (c) 1990-1995, S.R. van den Berg, The Netherlands.

Some legal stuff:

Use this software package at your own risk.  The programmer cannot
be held liable for any incurred damages, directly or indirectly due to
the use or inability to use this software.

You are encouraged to distribute this package freely.  This package is
however not to be sold (minor transfer costs excepted) or included in
any commercially sold software package (if you want to do this anyway,
contact me (address below), and we'll work something out).

If you distribute it, please leave the package intact.  You are allowed to
take parts from this distribution and distribute these separately as long
as you retain the copyright messages.  If you redistribute any part of this
package in a modified form, be sure to mark the parts you changed.
If you have some important changes that might be useful to the rest of the
world, contact me instead.

-------------------------- SYSTEM REQUIREMENTS -------------------------------

Any *NIX-alike (or POSIX compliant) system.

Sendmail, ZMailer, smail, MMDF, mailsurr or compatible mailers (in effect any
mailer that can process RFC-822 compliant mails).

For a fairly complete list of all C-library references done in the programs
see "src/includes.h".

------------------------------ DESCRIPTION -----------------------------------

The procmail mail processing program. (v3.11pre3 1995/05/17)

Can be used to create mail-servers, mailing lists, sort your incoming mail
into separate folders/files (real convenient when subscribing to one or more
mailing lists or for prioritising your mail), preprocess your mail, start
any programs upon mail arrival (e.g. to generate different chimes on your
workstation for different types of mail) or selectively forward certain
incoming mail automatically to someone.

Procmail can be used:
        - and installed by an unprivileged user (for himself only).
        - as a drop in replacement for the local delivery agent /bin/mail
          (with biff/comsat support).
        - as a general mailfilter for whole groups of messages (e.g. when
          called from within sendmail.cf rules).

The accompanying formail program enables you to generate autoreplies, split up
digests/mailboxes into the original messages, do some very simple
header-munging/extraction, or force mail into mail-format (with leading From
line).

----------------------

I made the utmost effort to make procmail as robust as any program can be
(every conceivable system error is caught *and* handled).

Since procmail is written entirely in C, it poses a very low impact
on your system's resources (under normal conditions, when you don't
start other programs/scripts from within it, it is faster and more
robust than the average /bin/mail you have on your system now).

Procmail was designed to deliver the mail under the worst conditions
(file system full, out of swap space, process table full, file table full,
missing support files, unavailable executables; it all doesn't matter).
Should (in the unlikely event) procmail be unable to deliver your mail
somewhere, the mail will bounce back to the sender or reenter the mailqueue
(your choice).

For a more extensive list of features see the FEATURES file.

----------------------

However, as with any program, bugs cannot be completely ruled out.
I tested the program extensively, and believe it should be relatively
bug free (no known bug at the time).  Should, however, anyone find any
bugs (highly unlikely :-), I would be pleased (well, sort of :-) to hear
about it.  Please send me the patches or bug report.
I'll look at them and will try to fix it in a future release.
(BTW, if you should find any spelling or grammar errors in these files,
don't hesitate to point them out to me; I like correct English just as much
as you do).

----------------------

I would like to take the opportunity to express my gratitude in particular
to these devoted users of the procmail-package.  Without their constant
feedback procmail would not have looked the same:

        David W. Tamkin         An excellent proofreader and betatester

        Josh Laff               For stresstesting procmail (and me :-)

        Dan Jacobson            For his many useful suggestions

        Rick Troxel             Because I crashed his Convex way too often :-)

        Roman Czyborra          For his enthusiastic ideas

        Ari Kornfeld            The guardian angel of SmartList

----------------------

Please note that this program essentially is supposed to be static, that
means no extra features (honouring the VNIX spirit) are supposed to be
added (though any useful suggestions will be appreciated and evaluated if
time permits).

Cheers,
       Stephen R. van den Berg  at RWTH-Aachen, Germany.

Snail-Mail:     P.O.Box 21074
                6369 ZG Simpelveld
                The Netherlands

Procmail & SmartList updates and patches list (readonly):

----------------------
A recent version can be picked up at various comp.sources.misc archives.
The latest version can be obtained directly from the ftp-archive at:

        ftp.informatik.rwth-aachen.de (137.226.225.3)

as (g)zipped tar file:     /pub/packages/procmail/procmail.tar.gz       <160KB
as compressed tar file:    /pub/packages/procmail/procmail.tar.Z        <224KB
----------------------
--
// Kaelin Colclasure -------------------------------------------------------

// Voice: (314)567-8463                     717 Office Parkway
//   Fax: (314)432-5391                     St. Louis, MO 63141

Example:
cp /usr/mail/aites tmbox
agrep -d '^From ' 'breakdown;internet' tmbox

 outputs all mail messages (the pattern '^From ' separates mail messages in
 a mail file) that contain keywords 'breakdown' and 'internet'.

Note: if handling extremely large mail/data files, you may need to compile
      agrep with a larger buffer.  (as mentioned in the README)

- Not that it matters, but this is my FAVORITE command! -
-jim-

        I am in the process of developing an API suite and have created
        object archives for easy linking for user Apps that will call them.

        I want to make them sharaeble objects.

        Q1 How do I go about doing that?
        Q2 Is there an advantage doing that over a regular '.a' file?

        I am on a SunOS 4.1.3 machine. I tried "man -k shareable" w/ no luck.

        All help/hints will be appreciated.

        Thx,
        Lakshmi

Quote:>    I am in the process of developing an API suite and have created
>    object archives for easy linking for user Apps that will call them.
>    I want to make them sharaeble objects.  
>    Q1 How do I go about doing that?
>    Q2 Is there an advantage doing that over a regular '.a' file?
>    I am on a SunOS 4.1.3 machine. I tried "man -k shareable" w/ no luck.

Hope this helps, some greetings from rainy Aachen (germany)
        Joerg Bredno

Quote:>    I want to make them sharaeble objects.
>    Q1 How do I go about doing that?

Quote:>    Q2 Is there an advantage doing that over a regular '.a' file?

There are gotchas. Overwriting the library can cause existing *processes*
to crash, when they next page in from the library. Executable start-up
time is slightly longer, because of the linkage process. It's possible
to get your linkage paths confused, so you're linking against the wrong
library. Version management becomes more of an issue. But these are just
minor gripes.

A different point is that ideally, the code shouldn't contain any static
data, because that's not text, and so means the object can't be shared
in memory across multiple processes. Instead, static data should go into
mylib.sa.m.n, which is a normal archive file. It gets linked with the
executable statically, so each process gets a copy. This means the
static data has to have a public symbol, though. Not good. I believe that
Sun have fixed this in SunOS 5.x. Certainly, the .sa files have vanished.

steve

--

ISPs are responsible for maintaining the Information Superhighway. They
are not responsible for how you drive.      #include <std_disclaimer.h>

A sample makefile:
--------cut here---------
OBJS = f1.o f2. o f3.o

.c.o:
        gcc -pic -c $<

libmyfirst.so.1.0: $(OBJS)

--------and here----------

If the -assert pure-text test failed, this means that some of your object
files also contained data; i.e. writable global variables. In that case you also
have to make a static part of the library; the .sa file. See the SunOS
documentation for more info on this subject
--

University of Twente, Lab. meettechniek&instrumentatie \  not wars.

        Thanks for pointing me in the right direction.
        Appreciate your help.

        All of what you said is accurate. I am reading up on them.

        Thanks a Mil
        Lakshmi