I've found your other thread about the same subject and have answered there - it is a known problem.

Hello all,

I'm running Pegasus Mail 4.41 and have set up filtering rules to extract, then delete, attachments from certain messages that tend to be large. Attachments get extracted OK, but remain part of the message. The help file says attachments can only be removed while the message is still in the inbox, so I have taken care processing attachments before moving the message. My rules look like this:

# MList
If header "S" contains "[MList]" Goto "MList"
If not ListScan "@MList.PML" Goto "!MList"
Label "MList"
If attachment NamePart matches "*" SaveAttmt "C:\\Documents and Settings\\Erik\\My Documents\\MList\\Att" 1
If attachment NamePart matches "*" DeleteAttmt ""
If attribute 545259523 Dialog "Attachments saved for MList"
Always Move "3EC3E6EC:29D6:FOL00EC2"
Label "!MList"

So, attachments are saved and the message box appears, but deletion fails. It is still possible to remove them if I manually return the mesage to the inbox first.

I'm grateful for any hints on how to make this work.

Best regards,

Erik
 

You need to get this delivered and processed in the new mail folder. Try removing that "Always move" line and shift this move to a filter that works when you close the folder. 

Thomas,

thanks for the quick reply! I tried your suggestion and got so-so results, some of which I can't quite explain. My test message was one with a subject triggering the group of rules, message body with some short text and no formatting, plus an attached .txt file. This is the outcome:

First, I moved the group of rules to the top of the filter set to avoid an unexpected "Move" triggered by preceding rules. Still did not work.

Then I temporarily disabled the "Always move". Et voilà: Attachments where now deleted, but so was the message body. My target directory contained the attached .txt file and the "-" file (saying that "The following section of this message contains a file attachment..."). There was no trace of the message body in the target directory. I suppose that "-" name is used for any anonymous attachment, and that the msg body was overwritten by the other section. After changing the regexp from "*" to "?* " the message body remained in the email. Good!

Next, I moved the group of rules back to their original place, "Always move" still disabled. This worked, too, so the "Always move" seems to be the problem rather than a "Move" triggered by preceding rules.

Then I attached a new folder-close filter set to the "New mail" folder. It just contained an "Always move" to a temp folder. This didn't work at all. I tried detaching and re-attaching filter sets, closing/restarting Pegasus, all to no avail. All messages, read and unread, stayed in the "New mail" folder.

- - - 

Maybe I am missing something here. My understanding was that rules (other than GOTO and the like) are applied in strict top-down order and that each rule is evaluated in isolation (except, maybe, AND). The results of my test indicate that the "Move" was actually performed before the preceding rules, thus preventing attachment removal. Does PM run attachment filtering rules out-of-order?

Splitting the extraction from the move means duplicating the matching rules, which I am a bit reluctant doing because of the maintenance headache. Is there any way to avoid that?

And, since the folder-close filter has no effect at all, what can I be doing wrong?

Thank you for helping!

Erik

Move always bypasses normal delivery and the attachments are only removed in the process of writing the CNM file to the new mail directory.  If you want to remove attachments the message must be delivered normally, i.e. no move.  The body of a MIME message is actually an attachment (i.e. MIME message part) and if you are deleting all attachments then you will be deleting the message body as well.  You need to be triggering on the MIME headers in the message parts to ensure that you are only deleting message parts that contain files.

As for the close filter not working are you actually opening and closing the new mail folder or are yuo using the preview mode.  Moveing through a folder via preview does not operate on close filter for obvious reasons.

Thomas,

thanks for the information, that really helped me understand what is (not) going on. 

[quote user="Thomas R. Stephenson"]

Move always bypasses normal delivery and the attachments are only removed in the process of writing the CNM file to the new mail directory.  If you want to remove attachments the message must be delivered normally, i.e. no move.

[/quote]

That explains the behaviour I observed. IMHO this is pretty confusing, and when combined with attachment rules it breaks the power of mail filtering. At least for someone like me, relying on automatic filtering into several folders to keep my inbox clean. Perhaps I should consider posting to the Wishlist, if I can come up with something that doesn't break things.

[quote user="Thomas R. Stephenson"]

The body of a MIME message is actually an attachment (i.e. MIME message part) and if you are deleting all attachments then you will be deleting the message body as well.  You need to be triggering on the MIME headers in the message parts to ensure that you are only deleting message parts that contain files.

[/quote]

Checking for a file name of more than one character is a crude way to keep the message body part, but it seems to work reasonably well. If I understand things right then attachment rules only check file names (full or part) and "normal" rules check the message in its entirety. How do I trigger on the MIME headers of a specific message part?

[quote user="Thomas R. Stephenson"]

As for the close filter not working are you actually opening and closing the new mail folder or are yuo using the preview mode.  Moveing through a folder via preview does not operate on close filter for obvious reasons.

[/quote]

This may be a misunderstanding on my part. In the context of the three-pane tree/list/preview interface, I interpreted "close" as meaning selecting another folder, as there is really no other opening or closing of folders. So although I was not moving through (the messages of) the folder, I was moving through the folders in the tree pane.

So I tried turning preview mode off, which made no difference. Then I opened the "New mail" folder in a window of its own, which I then closed. Nothing happened. Next I opened the "New mail" folder in a window of its own, selected another folder in the three-pane view before closing "New mail". It still did not work. Finally I tried doing the same, but actually closing the three-pane view before closing "New mail". Not even that worked.

Is there still something that I misunderstand?

Cheers,

Erik 

Update on the "New mail" folder-close filter:

It seems this folder is treated differently than other folders when it comes to attached filter sets.

Filters can be attached via the context menu just as for any other folder, but they have no effect. However, the "Mail Filtering Rule Wizard" has an option to apply the defined rule when the new mail folder is closed. Selecting this option creates a WINRULEA file, which is automagically run when the "New mail" folder is closed. Different from other attached filters, there is no indication (check mark) in the context menu. It also only applies to the separate folder window, selecting a different folder in the tree view does not invoke filtering. Rule sets attached to other folders run when folder selection changes in the tree view, there is no need to open the folder in a new window to apply a filter.

So it sort of works, but I would prefer mail filtering to be fully automatic. Moreover, the WINRULES set is applied a second time when the "New mail" folder is opened in a window of its own. This is unnecessary at best, and will cause unwanted side effects for COPY, FORWARD and SEND actions.

I would be very grateful for any hints on how to regain automation, avoid side effects or avoid rule duplication in WINRULES and WINRULEA. Any explanation of when the current behaviour is required or expected would also be welcome.

Cheers,

Erik 

> This may be a misunderstanding on my part. In the context of the
> three-pane tree/list/preview interface, I interpreted "close" as
> meaning selecting another folder, as there is really no other
> opening or closing of folders. So although I was not moving through
> (the messages of) the folder, I was moving through the folders in
> the tree pane.

When scanning through folder in the preview mode you really do not want the close filter to say move or delete messages you have never read.  The then on close filter on works when you specifically open the folder and then close it.

>
> So I tried turning preview mode off, which made no difference. Then
> I opened the "New mail" folder in a window of its own, which I then
> closed. Nothing happened. Next I opened the "New mail" folder in a
> window of its own, selected another folder in the three-pane view
> before closing "New mail". It still did not work. Finally I tried
> doing the same, but actually closing the three-pane view before
> closing "New mail". Not even that worked.

Are you sure you created a new mail filter that works on closing?  This does work.

FWIW, you are not going to be able to accomplish what you want until there is a capability of actually deleting attachments in a folder other than the new mail folder.  As it is, the message must be delivered to the new mail directory as a CNM file before the attachment deletion takes place.  All filters you work with must take this into consideration.


>
> Is there still something that I misunderstand?

[quote user="Thomas R. Stephenson"]> This may be a misunderstanding on my part. In the context of the
> three-pane tree/list/preview interface, I interpreted "close" as
> meaning selecting another folder, as there is really no other
> opening or closing of folders.

When scanning through folder in the preview mode you really do not want the close filter to say move or delete messages you have never read.  The then on close filter on works when you specifically open the folder and then close it.
[/quote]

There might be some difference in how automatic filtering of incoming massages and on-open or on-close filter sets are generally used. Other than that, I disagree - moving messages before I have read them is exactly what I want to accomplish.

I can see the point when it comes to message deletion, although I would personally prefer just a warning in the documentation.

[quote user="Thomas R. Stephenson"]<...>
> Finally I tried
> doing the same, but actually closing the three-pane view before
> closing "New mail". Not even that worked.

Are you sure you created a new mail filter that works on closing?  This does work.
[/quote]

Yes. I created a rule set and attached it as a folder-close filter set to the "New mail" folder. Further testing revealed that attached filter sets don't work at all on this specific folder. Only the WINRULEA filter set has any effect on close of "New mail", and then only when closing the separate single-window folder view.

BTW, folder-open and folder-close filter sets attached to other folders kick in as soon as the corresponding folder is selected or unselected in the folder tree. There is no need to open or close the separate single-window folder view.

[quote user="Thomas R. Stephenson"]
FWIW, you are not going to be able to accomplish what you want until there is a capability of actually deleting attachments in a folder other than the new mail folder.  As it is, the message must be delivered to the new mail directory as a CNM file before the attachment deletion takes place.  All filters you work with must take this into consideration.
[/quote]
I realize that and will accept it for the time being. This really should be explained in the docs. I may be able to contribute some prose, if members of this forum supply me with whatever pieces of information they have. Any hint, observation or pointer to other relevant threads would be helpful.

Cheers,

Erik 

[quote user="pmerik"]BTW, folder-open and folder-close filter sets attached to other folders kick in as soon as the corresponding folder is selected or unselected in the folder tree. There is no need to open or close the separate single-window folder view.[/quote]

For filter-open rules, this depends on the setting of 'Apply filtering rules when previewing..' in Tools/Options/Preview mode settings.  Filter-close rules only work for me when I fully open a folder and then close it - as Thomas describes.

[quote user="PaulW"]For filter-open rules, this depends on the setting

of 'Apply filtering rules when previewing..' in Tools/Options/Preview

mode settings.  Filter-close rules only work for me when I fully open a

folder and then close it - as Thomas describes.[/quote]

PaulW,

Thanks for the input. I have that setting enabled, and can confirm that it works as you describe for most folders. Do folder-open and folder-close filters work for you, when attached to the "New mail" folder?

To correct and clarify what I wrote before, this is what I see:

• Attached folder-open filters run when a folder is selected
• Attached folder-close filters require opening and closing of the separate folder window. Any folder-open filter runs for the second time when the folder window opens
• No attached filter has any effect on the "New mail" folder. WINRULES and WINRULEA filters run implicitly, WINRULEA only when separate folder window is closed.
  

Sorry for the confusion.

[quote user="pmerik"]Thanks for the input. I have that setting enabled, and can confirm that it works as you describe for most folders. Do folder-open and folder-close filters work for you, when attached to the "New mail" folder?[/quote]

The new mail folder (NMF) is not a real 'folder' as the other folders are - it is just the collection of new messages (*.cnm).  It also has its own separate filtering rules as you state.  As far as I am aware, attaching general rule sets to NMF has no effect.

What is the code just to delete an attachment?

If attachment NamePart matches "?* " DeleteAttmt "" 

This does not work for me - yet.

[quote user="HolyHarp"]What is the code just to delete an attachment?

If attachment NamePart matches "?* " DeleteAttmt "" 

This does not work for me - yet.[/quote]

You have a space character in there.  You also don't need the '?' if you have the '*' matching on any name.

Paul,

  I'm not sure why but if I use just the "*" in the regular expression then Pegasus hangs.  From the above 1 April post we have:

"Et voilà: Attachments where now deleted, but so was the message body.

My target directory contained the attached .txt file and the "-" file

(saying that "The following section of this message contains a file

attachment..."). There was no trace of the message body in the target

directory. I suppose that "-" name is used for any anonymous attachment,

and that the msg body was overwritten by the other section. After

changing the regexp from "*" to "?* " the message body remained in the

email. Good! 

     It's a funny thing though:  "*" works in the regular expression when saving attachments but it makes Pegasus hang when deleting attachments.  I think it might delete the attachment but it saves it in such a way that the New Mail Folder process can't handle it (goes into an infinite loop or something).

You'll have to give us more information as to what you are trying to do - which folder is the message in? does it have other message parts? what other filter rules are you using? Does this problem occur with every message or just some?

Paul,

     I'd like to save and delete attachments to messages in the new mail folder.  I've got the save part down OK but the delete part isn't working.  Those are the only 2 filter rules I'm using.  I'd like to develop a filter that I can use as a general filter.  The problem occurs with all messages with attachments.  I haven't tried to see if it hiccups if none of the messages in the folder are attachmentless.