I have been trying to create a rule that will extract any .tif attachment that arrives in an email and put it in a directory. I can't get it to work.
I am using Mercury/32 v 4.01b 05Dec2004 version on Windows Server 2003. I created a new general rule called detach.rul
Here is detach.rul
********************************************************
Mercury Rule Set
# Rule to extract TIFF attachment to dir
If header "S" contains "Fax Server: Fax Received" Goto "detach"
Label "detach"
Always Copy "faxin"
If attachment ExtnPart contains ".tif" SaveAttmt "\\aimg-s1\faxin"
**********************************************************
I have a local user called faxin
created an alias called faxin with real address = Filter:C:\Program Files\MERCURY\detach.RUL
Nothing happens when an email with a TiF attachment arrives for faxin@aimg.com (email does arrive to faxin mailbox but not extraction occurs)
Any idea what I am doing wrong?
Thanks,
I would try something like this:
Mercury Rule Set
If header "S" contains "Fax Server: Fax Received" Goto "detach"
Always Exit ""
Label "detach"
Always Copy "faxin"
If attachment ExtnPart contains "tif" SaveAttmt "t:\\faxin"
In this case t: could be a local disk or a drive letter assigned to a share on another computer (aimg-s1).
By the way, there may be a small bug in the dialog "Rule based on attachment filename". When selecting action "Save attachment to file" clicking "Set..." doesn't work.
/Rolf
Rolf,
Thanks for your assistance. The rule is now being applied but the last line (If attachment ExtnPart contains "tif" SaveAttmt "t:\\faxin") is not being executed. I have tried changing the "t:\\faxin" to "d:\" but still notihgn. Do you know if the syntax of that line is correct?
Thanks you,
Eric Reichard
Hello!
I have compared your source code to the one I have in my filtering rules. Having done so, I now have two ideas what to change:
(a) The file extension to search for may be *.tiff (instead of a simple *.tif). Several image editing tools use *.tiff as the file extension for those files when saving them.
(b) The source code you quoted does not have a closing "1" at the end of the filtering rule.
(a) is simple to handle. The first part of the source code could be If attachment ExtnPart lists "tif, tiff". If you want to edit the filtering rule in the filtering rules Editor, do not forget to check the option "This string is a list of possible values, separated by commas".
(b) "1" at the end of the source code line tells Pegasus Mail to interpret the path given for "SaveAttmt" as the directory where to save the attachment. If there is no "1" at the end, Pegasus Mail uses the value for "SaveAttmt" as the file name to save the attachment with. (At least, this is what I think it works.)
When editing the rule in the filtering rules Editor, click on the "Set..."-button (provided you have chosen "Save attachment to file" as the action). If you check the option "Save the attachment using the filename encoded in the message", you should enter the directory where to save the attachment - if you do not check that option, you should enter the actual filename to be used for saving the attachment.
I think you may have forgot to check the option.
Perhaps, the following source code may help you: If attachment ExtnPart lists "tif, tiff" SaveAttmt "C:\\save_here" 1
EDIT: I am sorry...after reading the whole thread again, I am not that sure anymore that my suggestion really works. :-( I did not see that you had posted the original question in the Mercury forum; however, I had Pegasus Mail in mind when replying. As I have not used Mercury a lot, I am not sure whether my advice is really helpful for Mercury as well. Sorry for the confusion. :-(
The example I gave above was taken from a Pegasus Mail filtering rule set, so do not be surprised if it differs from the filtreing rule sets Mercury generates.
Hello! [quote user="Rolf Lindby"] By the way, there may be a small bug in the dialog "Rule based on attachment filename". When selecting action "Save attachment to file" clicking "Set..." doesn't work.[/quote] I have just tried that, and I am able to click on "Set...", opening the window in which in can choose how to handle an attachment.
EDIT: I am sorry...after reading the whole thread again, I am not that sure anymore that my suggestion really works. :-( I did not see that you had posted the original question in the Mercury forum; however, I had Pegasus Mail in mind when replying. As I have not used Mercury a lot, I am not sure whether my advice is really helpful for Mercury as well. Sorry for the confusion. :-(
All I can say is that "Set.." does work in Pegasus Mail; as I have not used Mercury a lot, I am not sure whether and when "Set..." does not work.
This may be a bigger problem than I first assumed. I made a local test setup of Mercury 4.51 (without any daemons etc), and I'm not even getting a simple general rule like this to work:
Mercury Rule Set
Always Move "admin"
It actually seems like Mercury doesn't execute the rule set at all. I've also restarted the program in case it didn't load the rule immediately, but that made no difference.
The Set... button doesn't work for me in Mercury (XP, Server 2000) with "Save attachment to file" selected.
/Rolf
Rolf and Thomas,
Let me start by thanking you for your assistance. In my case, the rule is being executed in full with the exception of the line that is supposed to extract the TIF attachment to a local folder.
I have made several changes so here is the entire rule as it is right now:
*********************************
Mercury Rule Set
# Rule to extract TIF attachments and copy email to faxes mailbox
Always Copy "faxes"
If header "S" contains "Fax Server: Fax Received" Goto "detach"
Always Exit ""
Label "detach"
If attachment ExtnPart contains "tif" SaveAttmt "E:\\" 1
**********************************
I know the rule is working because of the following:
1- When an email is sent to the alias fax_in@aimg.com (which triggers the rule), the email is copied to the local mailbox "faxes" as stated in the line: Always Copy "faxes"
2- If I move the "Always Copy..." line to just after "Label detach," it still copies the email. That must mean the "If header S..." line is being executed.
3 - Only the "If attachment ExtnPart..." line is not being executed. This line was produced by using the Mercury GUI so I must pressume the syntax is correct. Doing some research, I have modified the last part of this line to various suggestions. I have tried "@E:\\", "@E:\", "E:\\" 1, and a few others. Invariable the attachment is not extracted. As of right now I am generating the test emails so I am 100% sure the attached files have a .tif extension.
My only conclusion at this point (and I will continue to try) is that the syntax generated by the Mercury/32 GUI is not correct. I would hope that the development team could tell me what is the correct syntax for the line: If attachment ExtnPart contains "tif" SaveAttmt "E:\\" 1
I will accept any suggestions.
PS: The only objective of this rule is to extract TIF attachments received on this alias address and forward the email to a local mailbox (attachment and all).
Thanks again for all your help.
Eric Reichard
I tested this again, without the stupid alias mistake that mixed things up for me the previous time. The problematic line is, as you say, this one:
If attachment ExtnPart contains "tif" SaveAttmt "E:\\" 1
If I select some other action, like Log to console, I get a hit, so the extension is correctly identified. If I enter a full filename instead of a directory name for Save attachment it works perfectly. It's however not clear what the correct syntax for entering a directory name should be - apparently it differs from Pegasus. Does anyone know?
The Set... button still doesn't work here in conjunction with Save attachment to file. Works in all other cases, though.
/Rolf
Hello,
ist there any news about this problem?
I have exactly the same problem with Mercury32 V 4.51 on a PC with Win2000.
The Set Button does not work and any tries to add the rule manually didn´t not work out.
Did somebody found out the correct syntax for this rule?
I use the following RuleSet to remove possibly dangerous Attachments and add a informative text to the mail, but these Attachments should be stored in a special folder, so they are availabe for later inspection and possibly manual forwarding to the recipient.
If attachment ExtnPart lists "PIF,LNK,SCR,VBS,SHS,BAT,COM,EXE,CMD,EML,CPL,VBE,WBT,WSH" InsertText "C:\\Attachment_removed.txt"
If attachment ExtnPart lists "PIF,LNK,SCR,VBS,SHS,BAT,COM,EXE,CMD,EML,CPL,VBE,WBT,WSH" SaveAttmt "C:\\Removed_files\\"
If attachment ExtnPart lists "PIF,LNK,SCR,VBS,SHS,BAT,COM,EXE,CMD,EML,CPL,VBE,WBT,WSH" DeleteAttmt ""
The first and last Rule works, but the middle one doesn´t. The Save directory exists.
Regards, Homer
[quote user="Homer"]The Set Button does not work and any tries to add the rule manually didn´t not work out. [/quote]
*Sigh*, I can't *believe* we didn't fix that. I was *sure* it had been done, but I've just checked, and you're quite right: the button still doesn't work.
I'll see if I can put together a patch for this soon (sometime this week if I can).
Cheers!
-- David --
[quote user="David Harris"]
I'll see if I can put together a patch for this soon (sometime this week if I can).
Cheers!
-- David --
[/quote]
Thanks for the response! Sounds good!
Regards, Homer
Is it possible to add extracting to a directory (as in Pegasus) rather than just a specified filename?
This is probably a wishlist item but what about using ~Y ~M ~D etc (and sender / recip.) placeholders for foldername?
Just to let you know that I haven't forgotten about this (I have a note attached to my monitor reminding me to look into it); my last week has been rather complicated, though, and I'm behind on issues like this.
Please bear with me.
Cheers!
-- David --
This problem is fixed in the v4.52 release, which should be out tonight or tomorrow. The "Set" button now works, and you have the option of specifying either a filename or a directory: if you specify a directory, Mercury will use the filename transmitted with the message to create the file and place it in the specified directory. Note, though, that in either case, any existing file with the same name will be overwritten. In a future version, I will probably change it so that the filename is changed in a predictable way (for instance, by adding a number in brackets at the end of the filename part), which will allow multiple instances of files with the same basic name, but that was more than I had time to code into v4.52, given that the patch is urgently required for security reasons.
Cheers!
-- David --
Your previous draft for topic is pending
If you continue, your previous draft will be discarded.