According to my staff this works ok. We host hundreds of clients that we also serve with service and support, so for them this one does the trick. We're moving away from deploying Mercury or Exchange into the local environments due to the elevation of costs (man hours) to maintain multiple solutions. For those that want we host Exchange, file-servers, remote desktops  etc - but having an auto-print installed on a critical server is not something I'd recommend out of stability reasons. There is nothing worse than software that doesn't release resources, and no programmer locates all circumstances were bugs arise - so we tend to stick to a KISS principle, still.... 

Thanks for the input, good ideas are always fun to toss around.

Hi all,<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

More and more of our suppliers offer to send the invoices as PDF, to save the environment - but according to our book-keeping laws, everything here has to be audited. Meaning I have to carry the cost of printing the PDF-Invoices.

Does anyone know how to set up automatic print-out of attachments, either on the client side, or in Mercury?

A quick thinking about this would be to have a special mail-print client, that collects and prints any pdf attachment sent to a particular mail drop, and relays the rest to a persons' mail drop.

/Peter

Peter - I have never done what you are asking, though I can offer a few ideas how autoprint might be done, given that I have used similar processes to do some other things with applications called by Mercury.

These are the steps that I would probably take:

1. Test each received e-mail message to see if it contains a PDF attachment.  This can be done by using a regular expression test on message bodies, looking for a "filename=xxxx.pdf".

2, As the next command in the filtering process, call a program.  The purpose of the program is to extract the filename from the temporary file.  This could probably be done with a .bat or .cmd script though personally, I would use Unix tools for Windows.  Using Unix tools it is very easy to extract the filename using grep and cut commands.  Once the filename has been extracted, write it to another temporary file.  This is required as, so far as I can see, Mercury filter processing cannot actually extract the file name.

3. After 1. and 2. are completed, let Mercury processing continue.

4. There is now a "gotcha".  It would be nice to carry straight on and print the PDF file from the first temporary file that was made in 1.  However, the S/MIME content of the temporary file needs to be decoded first.  There maybe specific applications that coan do just this, but I am not aware of any.  The obvious way to do the decoding is to let the client mail application do it.  So far as I know, most (maybe all) major e-mail clients decode attachments to a temporary file.  This will be the file that you will want to print.  However, if you have to wait till the client connects and decodes the file, I think that it wll be necessary to run a daemon/background process to look for the file  (you know the filename at this point).  I presume that it will be somewhere in the "Temporary Internet Files" structure.

5. If you are able to find the file, it should be possible to print the file ias a background process using Adobe Reader (or Acrobat Professional, if you have it), using the process indicated in http://support.adobe.com/devsup/devsup.nsf/docs/52080.htm

There are a few unknowns in the above.  Certainly, if you can find a S/MIME decoder, this would be far easier to use than getting involved with the mail client.  In fact, I have just Googled "S/MIME decoder" and there are many hits, though I haven't investigated them.  Anyway, if any of these applications are suitable, you may be able to call them from the Mercury filter process and avoid having to deal with daemons and finding files from client temporary files etc.

I am sure that there will be some complications, e.g. what if there is more than one PDF attachment in a message.

Best of luck!  I would be interested to know if you succeed.

Gordon

Peter - I was curious to see if what I am suggesting will work.  I think it will.  The Acrobat Reader certainly works from the command line and I have printed a sample document.

To decode a base64 PDF attachment, there is a freeware application called b64dec.exe (Google will find it).  As long as you take the saved message file, cut everything out except the base64 encoding, I have successfully decoded a test PDF file.  Using an appropriate script (batch files or Unix Tools) it should be straightforward to extract and then print an arbitrary number of PDF attachments.  Using this method will avoid using a mail client altogether.

Gordon

Thanks for the input, we're mainly searching for a clientside solution, to be deployed. I found rather quickly http://www.automatic-print-email.com/, and asked my staff to test it on a dedicated mail drop.

I'll let you know how it turns out.

Peter - It sounds as if the solution you are looking at should do the job, if it does what the specification suggests.  It is also likely to be more elegant than what I was suggesting.  However, a client side solution does mean that you may have to manage multiple instances of the software.  This may not matter in your situation, of course.  A server side solution might be appropriate to a small office, but not if users are spread around and maybe at multiple physical sites.  In my case, I am the sole user and the client machines are within a few metres of the Mercury server machine, so which machine drives the printer is irrelevant.

Best of luck!

Gordon