Home > Archive > PERL Beginners > March 2005 > How to read and delete mail from a cron job
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
How to read and delete mail from a cron job
|
|
| John Moon 2005-03-15, 3:56 pm |
| Can someone please give me some suggestions (or pointers) as to how to read
and delete emails from a cron job. I will be receiving conformation email
and need to process it once then delete it - not process it again.
Thank you in advance,
John Moon
| |
| Chris Devers 2005-03-15, 3:56 pm |
| On Tue, 15 Mar 2005, Moon, John wrote:
> Can someone please give me some suggestions (or pointers) as to how to
> read and delete emails from a cron job. I will be receiving
> conformation email and need to process it once then delete it - not
> process it again.
Is procmail not an option?
This is exactly the sort of thing it's good at.
Procmail sits watching your incoming mail, then handles it in some way.
This usually means transferring the message to a specific folder, but it
could also mean running a program that transforms the contents of the
message (adding or modifying headers, etc), or doing something else --
as, in this case, you're trying to do.
For example, my Procmail rule to run SpamAssassin on incoming mail is:
:0fw: spamassassin.lock
| /usr/local/bin/spamc
If I just wanted to filter certain messages, I might do this:
:0fw: spamassassin.lock
* ^Subject:.*confirmation
| /usr/local/bin/spamc
You should be able to adapt this to your needs, and it should be much
more flexible than using a cron job.
(Note though that setting up Procmail, if it isn't there already,
requires some overhead. A lot of [Unix] mail servers are already set up
for it, and all you have to do is enable it for your account, but you'll
have to sort out what to do if you're starting from scratch. There's a
lot of good tutorials out there that a Google search will uncover.)
--
Chris Devers
| |
| John Moon 2005-03-15, 3:56 pm |
| Chris,
Thank you for the suggestion but when I say "process" I mean that I need to
read the "reply", grep for user id and a confirmation number, update my
database to say that the email I send was "replied to" as requested, and
that the email address I was given was correct... I am registering users for
access to web ap. and need(require) a good email address (initially!).
Plus I am not an admin but a developer and "procmail" is not a product I
believe I can use... (at least I can't find it on this UNIX box)
Anyone else?
jwm
-----Original Message-----
From: Chris Devers [mailto:cdevers@pobox.com]
Sent: Tuesday, March 15, 2005 9:03 AM
To: Moon, John
Cc: Perl Beginners
Subject: Re: How to read and delete mail from a cron job
On Tue, 15 Mar 2005, Moon, John wrote:
> Can someone please give me some suggestions (or pointers) as to how to
> read and delete emails from a cron job. I will be receiving
> conformation email and need to process it once then delete it - not
> process it again.
Is procmail not an option?
This is exactly the sort of thing it's good at.
Procmail sits watching your incoming mail, then handles it in some way.
This usually means transferring the message to a specific folder, but it
could also mean running a program that transforms the contents of the
message (adding or modifying headers, etc), or doing something else --
as, in this case, you're trying to do.
For example, my Procmail rule to run SpamAssassin on incoming mail is:
:0fw: spamassassin.lock
| /usr/local/bin/spamc
If I just wanted to filter certain messages, I might do this:
:0fw: spamassassin.lock
* ^Subject:.*confirmation
| /usr/local/bin/spamc
You should be able to adapt this to your needs, and it should be much
more flexible than using a cron job.
(Note though that setting up Procmail, if it isn't there already,
requires some overhead. A lot of [Unix] mail servers are already set up
for it, and all you have to do is enable it for your account, but you'll
have to sort out what to do if you're starting from scratch. There's a
lot of good tutorials out there that a Google search will uncover.)
--
Chris Devers
| |
| Felix Geerinckx 2005-03-15, 3:56 pm |
| on di, 15 mrt 2005 17:07:10 GMT, John Moon wrote:
> Plus I am not an admin but a developer and "procmail" is not a
> product I believe I can use... (at least I can't find it on this UNIX
> box)
>
> Anyone else?
http://search.cpan.org/~simon/Mail-Audit-2.1/ and a line in .forward
perhaps?
--
felix
| |
| Wiggins d'Anconia 2005-03-15, 3:56 pm |
| "Because it's up-side down.
Why is that?
It makes replies harder to read.
Why not?
Please don't top-post." - Sherm Pendley, Mac OS X list
Moon, John wrote:
> Chris,
>
> Thank you for the suggestion but when I say "process" I mean that I need to
> read the "reply", grep for user id and a confirmation number, update my
> database to say that the email I send was "replied to" as requested, and
> that the email address I was given was correct... I am registering users for
> access to web ap. and need(require) a good email address (initially!).
>
> Plus I am not an admin but a developer and "procmail" is not a product I
> believe I can use... (at least I can't find it on this UNIX box)
>
> Anyone else?
>
> jwm
Chris' point was that you can intercept the message as it is delivered
and process it in "real time" as opposed to having it sit in a queue
(read mailbox). So rather than checking periodically (via cron) that a
message has arrived, your process is kicked off when the message arrives
and gets fed its contents on STDIN. A very good way to handle incoming
mail. procmail and sendmail both handle this type of process, so if
procmail isn't available and sendmail is it will still work. The only
setup requirement is that you can point an address at a "pipe" but
regardless the address setup is virtually the same, and you will have to
have an address.... unless....
If you really just want to verify that the user can receive mail, then
rather than have them reply, why not just provide a link that they can
click on that will go to a specific URL with the confirmation
information in it. This tends to be easier than dealing with incoming
mail, as you will have to parse the message, etc. And you are really
testing their ability to receive e-mail and use your web site, rather
than their ability to send messages to your mailing lists, etc. (unless
that *is* what you are doing).
I have used the latter on several sites and other than the occasional
user who absolutely refuses to actually read the mail they get (in which
cases replying ain't going to help) it works very well.
http://danconia.org
| |
| John Moon 2005-03-22, 8:56 am |
| > Chris,
>
> Thank you for the suggestion but when I say "process" I mean that I need
to
> read the "reply", grep for user id and a confirmation number, update my
> database to say that the email I send was "replied to" as requested, and
> that the email address I was given was correct... I am registering users
for
> access to web ap. and need(require) a good email address (initially!).
>
> Plus I am not an admin but a developer and "procmail" is not a product I
> believe I can use... (at least I can't find it on this UNIX box)
>
> Anyone else?
>
> jwm
Chris' point was that you can intercept the message as it is delivered
and process it in "real time" as opposed to having it sit in a queue
(read mailbox). So rather than checking periodically (via cron) that a
message has arrived, your process is kicked off when the message arrives
and gets fed its contents on STDIN. A very good way to handle incoming
mail. procmail and sendmail both handle this type of process, so if
procmail isn't available and sendmail is it will still work. The only
setup requirement is that you can point an address at a "pipe" but
regardless the address setup is virtually the same, and you will have to
have an address.... unless....
If you really just want to verify that the user can receive mail, then
rather than have them reply, why not just provide a link that they can
click on that will go to a specific URL with the confirmation
information in it. This tends to be easier than dealing with incoming
mail, as you will have to parse the message, etc. And you are really
testing their ability to receive e-mail and use your web site, rather
than their ability to send messages to your mailing lists, etc. (unless
that *is* what you are doing).
I have used the latter on several sites and other than the occasional
user who absolutely refuses to actually read the mail they get (in which
cases replying ain't going to help) it works very well.
Thanks to all who replied...
I have used your suggestions and created a .forward file with a pipe to a
perl script... All works well...
jwm
|
|
|
|
|