Pegasus Mail & Mercury

I want to extract the From addresses from selected messages and then re-mail these messages to a mobile phone, possibly after some truncation or deletion of certain messages.  Although I might be able to do this (maybe not all) only using Mercury's filtering rule-set, I decided to try to try to do it using a batch file (.bat) executed from the filtering process.  Prior to running the batch file, I save the message to a file, using the appropriate filtering rule.  When the batch file is executed, it parses the message headers (using DOS Unix utilities; grep, cut, sed etc) in the file to find the From address.  I am then re-mailing some of the messages using blat from within the batch file.  This all works fine when the batch file is run in isolation, but as soon as I try to call it from the Mercury filtering process, I get no results (no From addresses are captured to a file where I am collecting them).  Can anyone offer any advice as to why executing the .bat file from within the filtering process doesn't work?

Thank you

GordonM

That batch file might be better run as a policy.  I recall reading about difficulties running batch files within filters.

 Is there any evidence the batch file is started?  Are you invoking the command interpreter (command or cmd)?

Can you please elaborate how the batch file can be run as a policy and why this might be preferable?

One step in the batch file is to create a sentinel file.  I then check for this in the following filter command.  There seems to be no delay in the filtering process, so this suggests to me that the batch file has been run, but I should probably check this again.

This is a .bat file, so I presume that it is using command.com.

There may be an issue about directory paths.  I am not using full path-names for some of the files, as they are in my MERCURY directory.  An example of this is that I am using the relative name for the Unix utilities (which reside in the MERCURY directory, e.g. wbin\grep "From: " C:\MERCURY\MessageFile.txt, rather than C:\MERCURY\wbin\grep "From: " C:\MERCURY\MessageFile.txt.  I will try the full path-name in all cases.

Thank you

Gordon

> Can you please elaborate how the batch file can be run as a policy and why this might be preferable?

Here's a sample of a batch file being run as a policy.  F-Prot for DOS was used by many via a policy until it finally went out of support.

Here's how to create a policy to scan all of the inbound and outbound mail through Mercury/32.  Essentially the only changes I've made were to keep the files and directories 8.3.  For testing go to http://www.eicar.org/anti_virus_test_file.htm and get a copy of the anti-virus eicar.com test files.

1.  Get a copy of the freeware F-Prot for DOS from
    http://www.complex.is/f-prot/Download.html and extract it to
    directory C:\f-prot.  

2.  Create a new policy using Configuration | Mercury core |
    Policies with the following parameters.

Policy name: Fprot Antivirus
Type: Run program using sentinel file
Commandline: C:\Mercury\Fprot.bat ~X ~R ~S ~F
Task requires attachment unpacking support
Action: Forward message to a local user

The Commandline: entry might have to be preceeded with command.com /c (or com /c for NT) but I've not needed to for either Win98 or NT.

3.  Create a C:\mercury\fprot.bat file using the following
    information.

---start batch file---
@echo off
: Rem - %1 is the file to scan %2 is the name of the result file %3
: Rem - is the sentinel file. The report from the scan is sent to the
: Rem - Result file. If No virus is found then the Result file is
: Rem - deleted prior to deleting the sentinel file. If a virus, or
: Rem - other error is found, then a message indicating the meaning
: Rem - of the return code is tacked on to the end of the result
: Rem - file. Deletion of the sentinel file is the last thing that
: Rem - takes place.
: Rem - Note 1: Some of the error codes should never occur, in this
: Rem - context, but I put them in anyway for documentation purposes,
: Rem - if nothing else.
: Rem - Note 2: There's colons in front of the Rem statements because
: Rem - blank labels process faster than Rem statements (the entire
: Rem - Rem statement is parsed even though it's a comment)
: Rem - No extended batch command features are used so this should
: Rem - work with*any* MS OS.
: Rem - Watch for wrapping of the batch file lines in this email
: Rem - message.  They are longer that the normal 70 CPL!.  The
: Rem - F-PROT commandline and echo line should NOT be wrapped.
C:\F-Prot\F-prot.exe %1 /ARCHIVE /DUMB /TYPE /NOMEM /PACKED /REPORT=%2 /WRAP
If Errorlevel 8 goto err8
If Errorlevel 7 goto err7
If Errorlevel 6 goto err6
If Errorlevel 5 goto err5
If Errorlevel 4 goto err4
If Errorlevel 3 goto err3
If Errorlevel 2 goto err2
If Errorlevel 1 goto err1
Del %2
goto Finished
:Err1
echo Abnormal termination - Unrecoverable Error >> %2
echo Internal error. English.tx0 or Sign.def or Macro.def missing/corrupted >> %2
goto Finished
:Err2
echo Selftest failed - program has been modified >> %2
goto Finished
:Err3
echo !!!!!BOOT/FILE VIRUS FOUND!!!! ~F >> %2
goto Finished
:Err4
echo !!VIRUS FOUND IN MEMORY!! >> %2
goto Finished
:Err5
echo Program terminated via ^C or Esc >> %2
goto Finished
:Err6
echo Virus removed >> %2
goto Finished
:Err7
echo Insufficient memory to run the program. >> %2
goto Finished
:Err8
echo *SUSPICIOUS* file found, no known infection >> %2
:Finished
Del %3
exit
---end batch file---

Thomas - Thank you for the information about running a batch file as a policy.  I am going to check into one or two other loose ends first and then try out the policy approach.

GordonM

P.S.  BTW, I am seeing three copies of your reply, each with slightly different submission times.

P.S.  BTW, I am seeing three copies of your reply, each with slightly different submission times.

My fault, I was doing a "quick" reply and there was no post.  Did it a second time with the same result.  Finally did a normal reply and the group came back as moderated.  I've notified peter of the problem.

I suppose that I should have thought about this but, when I replaced all relative (to MERCURY) pathnames with full pathnames, everything worked fine.

I don't seem to need to use the Policy approach, but I will try this just to gain some familiarity.

Thank you to those assisting in getting me there.

GordonM