Automatic email-handling, hints needed

Automatic email-handling, hints needed

Post by Soeren Holstebro » Thu, 24 Aug 1995 04:00:00



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.

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

 
 
 

Automatic email-handling, hints needed

Post by Clay Helbe » Thu, 24 Aug 1995 04:00:00


: 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.

: 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....

 
 
 

Automatic email-handling, hints needed

Post by Kaelin Colclasu » Fri, 25 Aug 1995 04:00:00


   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

 
 
 

Automatic email-handling, hints needed

Post by Jim Ait » Tue, 29 Aug 1995 04:00:00


I'm using 'agrep' to grab specific things from my mailbox for parsing or
re-mailing...also restoring the real mbox after stripping said items.

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-

 
 
 

Automatic email-handling, hints needed

Post by Lakshmi Narayana » Tue, 29 Aug 1995 04:00:00


Hi guys,

        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

 
 
 

Automatic email-handling, hints needed

Post by Joerg Bred » Wed, 30 Aug 1995 04:00:00



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.

Don't know how SunOS will behave but with HP-UX
it can be done like this:
compile with +z as an option (see man page on
compiler for position independent code)
link with -b option (see man page on linker,
perhaps also called ld on shareable libraries)

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

 
 
 

Automatic email-handling, hints needed

Post by Steve_Kilba » Wed, 30 Aug 1995 04:00:00



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

It's been a while since I used SunOS 4.1.x, so this is from memory,
but (a) compile the .c files with -pic or -PIC, to make them
position-independent; (b) link them all together with
ld -assert pure-text -o mylib.so.m.n
where m is the library's major version number, and n is the minor
version number. There's a section of the printed manual that
describes all of this.

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

Two. When linked against such an object, the resulting executable doesn't
include the code internally. Instead, it dynamically loads it at run-time.
Thus, the executable takes up less space on the disk. Secondly, when there
are multiple programs using the same shared obj on a machine, they can all
use the same in-memory image, saving virtual memory. You can also update
the library without having to recompile the executables that use it.

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>

 
 
 

Automatic email-handling, hints needed

Post by Dick Snip » Wed, 30 Aug 1995 04:00:00




>>        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.

>Don't know how SunOS will behave but with HP-UX
>it can be done like this:
>compile with +z as an option (see man page on
>compiler for position independent code)
>link with -b option (see man page on linker,
>perhaps also called ld on shareable libraries)

An easy 2 step guide to generating shared libraries:
1) compile all your object files with option -pic to generate position
   independent code; i.e. 'gcc -pic -c f1.c f2.c ...'
2) use the linker (and not the compiler) to generate the library: i.e.
   'ld -o libmyfirst.so.1.0 -assert pure-text f1.o f2.o ...'

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.

 
 
 

Automatic email-handling, hints needed

Post by Lakshmi Narayana » Wed, 30 Aug 1995 04:00:00



>It's been a while since I used SunOS 4.1.x, so this is from memory,
>but (a) compile the .c files with -pic or -PIC, to make them
>position-independent; (b) link them all together with
>ld -assert pure-text -o mylib.so.m.n
>where m is the library's major version number, and n is the minor
>version number. There's a section of the printed manual that
>describes all of this.

        Steve,

        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

 
 
 

1. Automatic email-handling, hints needed

In
Xref: news.cs.ccu.edu.tw comp.unix.questions:3907 comp.unix.shell:2144
comp.unix.programmer:2416 comp.unix.admin:2696

We have created a more powerful search tool than agrep that makes the
management of email files more convenient.
It can extract 'arbitrary' large size of mails from mbox file
(so it's easy to extract uuencoded tar file from mbox) and it can
generate different kind of folders at will by specifying a query.
For example, suppose you want to extract all the emails from
all of your email files (folders) whose subject line contains "Internet"
what could you do? (agrep could not do this.)

With gais it's easy:
gais -r -d -mail 'Subject: [^\n]*Internet' MailDir
will trace the directory MailDir to collect all the emails
whose subject line contain "Internet".

As another example, suppose you want to extract all the emails that were
sent from Johnson, but you don't want those mails whose subject is
on win95, you can do
gais -d -mail 'From.*Johnson AND NOT Subject:.*win95' mbox > result
that have sent emails to you.

gais can be obtained by http connection:
http://gais.cs.ccu.edu.tw
or anonymous ftp: ftp.cs.ccu.edu.tw

For more information on gais please see http://gais.cs.ccu.edu.tw

--sun wu (the creator of agrep)
Internet ReSearch Lab.,
Dept. of C.S.I.E.
Chung Cheng University, Taiwan
http://www.cs.ccu.edu.tw/~sw

2. PROBLEM SETTINH UP IP SPOOFING PROTECTION

3. NEEDED: Tips for automating e-mail handling and replies

4. Apache requires "nph-" filename??? Non-parsed headers.

5. Automatic mail handling -- how to do it?

6. Matrox Mystique 220 vs. X Windows

7. Need e-mail remailer to send to address in body of e-mail

8. What X server should be used for IGA1682 Video Adapter (from Integraphic Technology)

9. automatic email reply with URL content

10. Automatic Email Responses

11. automatic e-mail reply

12. automatic email response?

13. E-mail automatic processing