The trick is to get file locking to work properly, so that two pieces of mail don't have the file open for writing at the same time. In my case, procmail handled this for me automatically.

On unix at least, mail is in some ways a better mechanism for web form submissions than HTTP POST or GET. It is more complicated to program, but it is more reliable since the clients do automatic retries when the server is down. It is best suited for jobs like yours, where you submit a single piece of data that needs to be saved, not an interactive interface.

1. Configure the server so when it receives an e-mail from specified addresses it should execute the Perl script passing the content of the e-mail as a param;
2. Make the Perl script read this param, discard 'useless' information from it (like the mail headers) and append the rest to a file. If you're talking about an Excel spreadsheet, you'll probably consider using Win32::OLE for the append step.

How about using CVS or SVN (control version systems) ?
There are many Perl support modules available in CPAN.

good stuff, granted, but overkill. we want it to be as easy as, "I just changed the firmware on all the switches to version X" send email. Then when the network has crashed, we can remind the guy to send the email first, then crash the network :)

The mailbox was checked once every 30 minutes with a script that ran for 30 seconds, so simultaneous file access was high unlikely--but not impossible.

Hmmm. If you are 'reading' a mailbox, as a mail client might, then it seems you wouldn't run into the need to lock the file.

I'd would approach the problem like so:

my $mboxfhandle;

# open $mboxfhandle for readonly

my @mbox = <$mboxfhandle>;  # Let's use lots of memory

# rest of the process ...
[download]

Seems like this would catch each new message, and not conflict with any incoming messages.

( on further reflections, I imagine that a mail client must be able to mark messages as read, which would involve a write ... )

-------------------------------------
Nothing is too wonderful to be true
-- Michael Faraday

I meant that simultaneous file access upon the *output file* was high unlikely--but not impossible--because the script should run for only 30 seconds every 30 minutes.

If you're using Unix, you don't even need a perl Script, you should be able to do it within the configuration file, 'aliases.txt'.

we need to update a html file on windows file server. :( long story that.

1. You don't have to make a "valid e-mail addresses" list, since this account will only receive e-mails from inside the company and therefore won't be "exposed" (if I've understood correctly).
2. You can even treat information that was or not logged by looking if the e-mail message was already read or not.

is there a free standing perl email reciever, like blat is to sending mail? the email server is on a different box.

The Net::POP3 module can access a POP3 mail account on any mail server accessible via TCP/IP.

The Perl script will need direct file access to the (HTML) output file.

Agreed, this would be my choice as well. While my first inclination would be to configure the mail server to launch a perl script when a particular address received mail, having a client read the mail gives you a lot of flexibility regarding where and when the perl script is executed.

Of course, it's up to you to determine things like the "correct" subject header and proper formatting of the message. But other than that it seems like a relatively simple deal.

PS & FYI, I love Log::Dispatch for writing messages.

It has great potential for document collection and other collaboration. changelog is also well fit.

kwiki and twiki are both written in Perl.

aliasname:            "|/path/to/script.pl"
[download]