Progress update:

I did some further testing with a folder of 4 emails, all of which

should trigger a rule to change the messages a different color. 

Dist

List1 - combination of real addresses and alias names. Results: The

emails matching the real addresses in the list were changed, the alias

emails were not changed.

Dist List2 - only real address entries in the list. Results: All emails were matched and colors were changed.

Dist List3 - only alias entries in the list. Results: No emails were matched and colors were not changed.

Final conclusion: If the distribution list contains real addresses, a "scan list" rule will work on matched emails. It will NOT work with alias names.

The real problem:

The PMAIL help documentation says a "scan list" will work with either

an alias name or an address. That is not true. Even more confusing, when

building a distribution list by selecting the entries from an address

book, the alias name is what is stored. That would lead a user to

believe that the alias name can be used in a scan list rule. I find no

place in the help doc that says a "scan list" must use a distribution

list with real addresses. Can this anomaly be fixed?

Earlier in this thread, user "twonotes" was chastised for calling this problem a "bug". I'm sorry, but I have to agree with his statement that the scan list function does not work as advertised and is therefore a "bug". Either the documentation should be changed to clarify the problem or the software should be changed to agree with the documentation.

Thanks to all that helped with this problem. At this point it appears my only recourse is to go back and rebuild this distribution list using real addresses. Bummer!

I have a filter rule with the "scan list" function pointing at a distribution list.  But it does not always work.  Is the scan comparison only done on the email address (the part in angle brackets) or on the entire name string, including the alias?  Does it properly look at the From header if there is no Sender header?

I apply this rules to IMAP folders, if that makes any difference.

[quote user="twonotes"]

I have a filter rule with the "scan list" function pointing at a distribution list.  But it does not always work.  Is the scan comparison only done on the email address (the part in angle brackets) or on the entire name string, including the alias?  Does it properly look at the From header if there is no Sender header?

I apply this rules to IMAP folders, if that makes any difference.

[/quote]

Only looks at the email address in the message.  There can be problems matching though if you have leading or trailing spaces in the dist. list IIRC.  The sender field is used if available.

I observe that when I build a Distribution List using the Distribution List editor, clicking on entries in my Address Book to add them to the list, what appears in the List is just the "Alias" part of the book entry.  But if I start with a message and right-click to get "Add sender's address to distribution list" it puts the entire address into the Distribution List.

Since the Alias I assign in my address book is how I think of the person rather than what their actual email address is (say "Bob" instead of "Robert.Smith") the Alias is hardly ever going to match, since "Bob" appears nowhere in the email address.   If the "scan list" filter operation goes only by the strings in the Distribution List rather than the actual email addresses in the Address Book, that would explain the behavior I see.

[quote user="twonotes"]

I observe that when I build a Distribution List using the Distribution List editor, clicking on entries in my Address Book to add them to the list, what appears in the List is just the "Alias" part of the book entry.  But if I start with a message and right-click to get "Add sender's address to distribution list" it puts the entire address into the Distribution List.

Since the Alias I assign in my address book is how I think of the person rather than what their actual email address is (say "Bob" instead of "Robert.Smith") the Alias is hardly ever going to match, since "Bob" appears nowhere in the email address.   If the "scan list" filter operation goes only by the strings in the Distribution List rather than the actual email addresses in the Address Book, that would explain the behavior I see.

[/quote]

 It sure does.  What I do is always use the paste addresses when using the addressbook and so the email address goes to the dist. list rather than the alias.  Now the scan list works quite well.

Ok, then it is a bug in the Dist-List editor.  But now that I know the workaround I can live with it.  Tnx.

[quote user="twonotes"]Ok, then it is a bug in the Dist-List editor.  But now that I know the workaround I can live with it.  Tnx.
[/quote]

No bug at all that I can see.   

The Dist List editor offers a way to create a Distribution List by selecting Address Book entries and clicking "ADD".  But it copies the useless ALIAS value to the list instead of the EMAIL ADDRESS.  That is the bug.  An ALIAS value may or may not every appear in an actual message, since they exist for the convenience of the sender.

[quote user="twonotes"]

The Dist List editor offers a way to create a Distribution List by selecting Address Book entries and clicking "ADD".  But it copies the useless ALIAS value to the list instead of the EMAIL ADDRESS.  That is the bug.  An ALIAS value may or may not every appear in an actual message, since they exist for the convenience of the sender.

[/quote]

No it is not a bug. If you want to call something a bug when it's operating as designed then go ahead, but it does not make it a bug.  The user selects how an addressbook works when pasting the email addresses.  The dist. list works quite well as a dist. list using either the alias or the email addresses.  If the user selects not to paste the addresses into a dist. list then the user has selected not to use the dist. list in a filter that checks for email addresses.  It's up to the user to setup a dist. list to be used how they want to use it. 

I have the same problem. I have set up a dist list with alias names using the dlist editor. I have set up a new mail rule using that dlist in a scan list filter. The filter doesn't work even though the alias name is included in the FROM: address in the mail. It appears to totally ignore the scan list filter. Any thoughts? 

I have never used the scan list filter but the help file reads "With this type of filtering rule, the rule will trigger if the sender's e-mail address can be located in a Pegasus Mail distribution list.".  There is no reference to aliases which makes me wonder if aliases won't work.  This is a very old thread after all.  Have you tried the rule using the email address?

Yes I have. That doesn't work either.

I will try to find time tomorrow to run a test to see if I can get a scan list filter to work.

Test results:  It appears that adding entries to a dlist from an addressbook is broken otherwise it worked as expected.

Test steps:

• Created a new dlist
• Added an entry from an addressbook (alias)
  
• Added an email address manually
• Added an email address using the right click context menu option (must click the "Select" button)
• Added a \MATCH entry (\MATCH *@domain.com)
• Created scan list rules that would change message color when triggered

Results:

• Rule was not triggered by the alias entry
• Rule was triggered by all other entries

[quote user="bfluet"]Test results:  It appears that adding entries to a dlist from an addressbook is broken otherwise it worked as expected. [/quote]

Clarification:  An alias added to a dlist from an addressbook entry does not work when the dlist is used in a scan list rule.  But, if the addressbook is configured to apply the e-mail address instead of the alias then an address added to a dlist from an addressbook does indeed trigger a scan list rule.

I just did the same thing as your test.

Set up a new dlist which looks like this (manual email, alias from addr bk, address extracted from a prev email, and \MATCH statement)

\TITLE TestScan
\NOSIG Y
bhenry004@gmail.com
BobHenryAz
paulahenry@cox.net
\MATCH *@gmail.com

Set up a new general rule set to use this dlist and change message color.

List Scan       @TestScanList.PML    Set colour to 'Bright magenta'  

Selected a folder which had mail from all these sources in it (they came from POP3 downloads) and did tools>mail filtering rules>apply general rule set to folder

Nothing happened.

System messages says:

Wed, 11:07:51    General rule processing: No messages triggered any rules.

I sure don't understand why. The procedure seems pretty straight forward. 

Is there some parameter I'm missing?  Is there an identity problem? Could POP3 be the problem? Should the .PML file be public or private?

This is driving me batty!

The only thing you did that I hadn't done was create a general rule set and apply it to a folder.  I just test that and it worked so I don't know what might be going on.  Just for curiosity sake try attaching the general rule set as a folder-open filter set and see if it works when the folder is opened.

Also, look in the appropriate RULE????.PMC file and see if the rule looks like this:

If ListScan "@TestScanList.PML" Highlight "2"

Another thought:  Be sure to use the 'Select' button to select the dlist when creating the rule.

Another test to consider:  Create a new folder then copy to it one of the messages that you expect will trigger the rule.  In the general rule set add an 'always trigger" rule above the 'list scan' rule.  Set the action to 'Message dialog and enter something like "Rule set triggered"as the parameter .  Attach it as a folder-open filter and test.  This will tell us whether the rule set is actually being run.  Don't test it on a folder with lots of messages because the always trigger rule gets triggered by each message.

See responses in bold.

The only thing you did that I hadn't done was create a general rule

set and apply it to a folder.  I just test that and it worked so I don't

know what might be going on.  Just for curiosity sake try attaching the

general rule set as a folder-open filter set and see if it works when

the folder is opened.

Attached TestScanList rule as folder open rule to InBox folder.

Opened Inbox folder.

Nothing happened. System Messages: Wed, 12:57:21    Newmail rule processing: No messages triggered any rules.

Also, look in the appropriate RULE????.PMC file and see if the rule looks like this:

If ListScan "@TestScanList.PML" Highlight "2"

Rule format is correct except that it says "9" instead of "2".

In PMAIL/MAIL/ADMIN/RULE7B56:

TestScan
If ListScan "@TestScanList.PML" Highlight "9"
 

Another thought:  Be sure to use the 'Select' button to select the dlist when creating the rule.

Created a duplicate rule set (TestScan2) and made sure to "select" the TestScanList dlist.

Applied general rule TestScan2 to folder.

Nothing. System Messages: Wed, 13:08:29    General rule processing: No messages triggered any rules.

Another

test to consider:  Create a new folder then copy to it one of the

messages that you expect will trigger the rule.  In the general rule set

add an 'always trigger" rule above the 'list scan' rule.  Set the

action to 'Message dialog and enter something like "Rule set

triggered"as the parameter .  Attach it as a folder-open filter and

test.  This will tell us whether the rule set is actually being run. 

Don't test it on a folder with lots of messages because the always

trigger rule gets triggered by each message.

Created folder called "Testing" and populated with a message that will trigger.

Added an "Always" trigger to TestScan rule to "Message Dialog" with a message "TestScan rule triggered". Saved the updated rule.

Tried several times to apply the rule using Tools>Mail Filtering rules>Apply general rule set to folder. Each time, nothing happened and no message appeared. In fact every time I applied it either as open-folder rule or apply-to-folder, the "Always" rule disapeared from the rule set. I recreated it several times but it didn't work.

System messages: Wed, 13:36:01    General rule processing: No messages triggered any rules.

Really getting frustrated!

I am baffled!  Even more so by your statement "the "Always" rule disapeared from the rule set. I recreated it several times but it didn't work.".   Applying a rule set to a folder or attaching one as a folder-open rule set should not result in any changes to the rule set. 

FWIW, the entry in System Messages should read "Newmail rule processing" when the rule set is attached as a folder-open rule set.

I hope there are forum members following this thread who some other suggestions.

Is Pegasus Mail installed to proper default location, c:\pmail

Do system and user have read/write/modify permission to all c:\pmail\mail and below?

Have we seen user display of the Help, About, Info button display yet?