[quote user="Rolf Lindby"]

There is a post on QCF flags in the Knowledgebase here.

/Rolf
 

[/quote]

Yes, I've seen that (long ago).  I don't recall if I ever made sense of the "ST" example:

Example: R 020528160331 12 000032 000030 000001
The R says this is a

retry, the next string is a date, time line,tells you when it will next

be processed. 2005 March 7 09:58:32 . The next one is the number of

tries, 3. The structure is critical, the data can be all zeros.

 Except for the "R", the explanation doesn't seem to match the example.

What will happen if I make a global filter like this:

HEADERS: From: person  AND To: list_name 

ACTION: CopyTo: other_person

Will other_person get one or several copies of each email?  Of course I want other_person to get only one.

You are right, that will get other_person 2 copies. Try this instead:

header From: person AND
not header Sender: maiser@ AND
header To: list_name Copy other_person

/Rolf 

[quote user="Rolf Lindby"]

You are right, that will get other_person 2 copies. Try this instead:

header From: person AND
not header Sender: maiser@ AND
header To: list_name Copy other_person

/Rolf 

[/quote]

I don't think "maiser" ever shows up in a "From:" header (disable header stripping?).  I'm worried about other_person getting a copy for everyone on the list.

[quote user="Vincent Fatica"]

What will happen if I make a global filter like this:

HEADERS: From: person  AND To: list_name 

ACTION: CopyTo: other_person

Will other_person get one or several copies of each email?  Of course I want other_person to get only one.

[/quote]

As a test, I made a list (stest) with two members and a filter:  IF From: contains person_X AND To: contains "stest" FORWARD to person_Y.  I, person_X send an email to the list "stest".  The first time through the core process, the rule was not triggered

19:56:11: Job MG000397:  person_X (non-local)
   To: :stest (local) -OK

Later, when mail was sent to the two members of "stest" the rule was triggered twice, once for each member, and person_Y wound up with two copies.  So, back to the drawing board.  Here's what I want:  when person_X sends mail to "list", I want person_Y to get a copy as simple as that.  Any ideas?


 

If you take a closer look at messages being delivered to a list you will notice that maiser will be in the Sender: header (which perhaps a bit surprisingly is not the same as the From: header). The rule I suggested works when I test it here. I believe we already agreed on what would happen if you used your original rule.

/Rolf
 

[quote user="Rolf Lindby"]

If you take a closer look at messages being delivered to a list you will notice that maiser will be in the Sender: header (which perhaps a bit surprisingly is not the same as the From: header). The rule I suggested works when I test it here. I believe we already agreed on what would happen if you used your original rule.

/Rolf
 

[/quote]

Emails to lists here do not contain a "Sender:" header, and do not mention "maiser".  Nevertheless, I tried your suggestion and got the same results as reported recently ... the original core entry (from person_X to (list) "stest") did not trigger the rule.  When the mail was delivered to the list menbers (with list name in the "To:" header) person_Y got a copy for each person on the list.

I haven't tested with older versions, but in Mercury 4.62 Sender is one of the headers added to messages delivered to list members, and maiser is the default name used here. "Disable header stripping" wasn't checked in my test.

In my first test (with your rule) other_person received one copy when the message was first accepted for delivery by core, and the other one when copies were delivered to the list members. Only the second copy did of course contain the Sender: header.

This is what the rule I suggested looks like in RULES.MER:

If header "F" contains "person" LogicalAnd ""
If not header "E" contains "maiser@" LogicalAnd ""
If header "T" contains "list_name" Copy "other_person"

/Rolf

[quote user="Rolf Lindby"]

I haven't tested with older versions, but in Mercury 4.62 Sender is one of the headers added to messages delivered to list members, and maiser is the default name used here. "Disable header stripping" wasn't checked in my test.

In my first test (with your rule) other_person received one copy when the message was first accepted for delivery by core, and the other one when copies were delivered to the list members. Only the second copy did of course contain the Sender: header.

This is what the rule I suggested looks like in RULES.MER:

If header "F" contains "person" LogicalAnd ""
If not header "E" contains "maiser@" LogicalAnd ""
If header "T" contains "list_name" Copy "other_person"

/Rolf

That's what mine look like (except I'm forwarding, not copying).  I was wrong, the first pass through core generates one copy (verified by making all members inactive).  But I'm getting two copies (though now there are 4 members) at the forwarding address.

[quote user="Vincent Fatica"][quote user="Rolf Lindby"]

I haven't tested with older versions, but in Mercury 4.62 Sender is one of the headers added to messages delivered to list members, and maiser is the default name used here. "Disable header stripping" wasn't checked in my test.

In my first test (with your rule) other_person received one copy when the message was first accepted for delivery by core, and the other one when copies were delivered to the list members. Only the second copy did of course contain the Sender: header.

This is what the rule I suggested looks like in RULES.MER:

If header "F" contains "person" LogicalAnd ""
If not header "E" contains "maiser@" LogicalAnd ""
If header "T" contains "list_name" Copy "other_person"

/Rolf

If I watch the core process, I see

TIME  to list "stest"

SAME TIME  to members of "stest"

SAME TIME  to forwarding address

Then, about 6 seconds later, on the next poll, I see, in the core process

TIME + 6 SEC  to forwarding address

It seems it's seeing the queued message (the forwarded one) which meets the filter criteria, and it generates another (or something like that).  This happens even if MercuryE (supposedly) empties the queue in the meantime.  MercuryE seems rather lazy about removing items from the queue.  In a test, I had the core plooing every 60 sec and MercuryE polling every 5 seconds.  The extra forwarded copy was generated 60 seconds (next core poll) after the first!

That's what mine look like (except I'm forwarding, not copying).  I was wrong, the first pass through core generates one copy (verified by making all members inactive).  But I'm getting two copies (though now there are 4 members) at the forwarding address.

If other_person is a local mailbox you can use Copy, if it's external you should use Forward. I tested with Forward here (all other things equal), and there is still just one copy received by other_person.

The 6 second delay you mention could be relevant, though, as it seems to indicate an action triggered by a message being delivered to one of the list members' mailbox. Could it be that one of the members has file-based forwarding to other_person as well?

/Rolf 

[quote user="Rolf Lindby"]

If other_person is a local mailbox you can use Copy, if it's external you should use Forward. I tested with Forward here (all other things equal), and there is still just one copy received by other_person.

The 6 second delay you mention could be relevant, though, as it seems to indicate an action triggered by a message being delivered to one of the list members' mailbox. Could it be that one of the members has file-based forwarding to other_person as well?

/Rolf 

[/quote]

It's a test list; all the persons on it are me; there's no automatic forwarding.  That 6 second delay was just the wait until the next core poll.  Even if I set the core to poll at 180 sec (E polling at 5 sec), 180 seconds after mail to the members and the extra one have been queued and long after they're deilvered, a second forwarded one is generated.  As I said earlier, if I make all members inactive, no second forwarded message is generated (as if the "NOT E contains maiser" isn't working).  Did you try it with header stripping disabled?  I upgraded to 4.62 ... the same.
 

I made these filters:

If not header "E" contains "maiser@" Dialog "bar"
If header "E" contains "maiser@" Dialog "foo"

 When I sent mail to me test list (with two active members) I got two of "bar" (regardless of the header stripping setting).  Why would "maiser" not be there?

Please check the MERCURY.INI file. In the [Maiser] section it should contain a line saying:

Maiser:          Maiser   # 'Username' of mail server account

If that line is missing there will apparently not be any Sender: header added to messages delivered to a list.

You could alternatively try to catch the Comment: header that's added to list messages instead, but that is not covered by the standard header rules and will require a regular expression rule. The header reads "Comments: Originally To: list_name", so the rule set could be:

If header "F" contains "person" LogicalAnd ""
If not expression headers matches "Comments: Originally To: list_name*" LogicalAnd ""
If header "T" contains "list_name" Forward "other_person" 

/Rolf 

[quote user="Rolf Lindby"]

Please check the MERCURY.INI file. In the [Maiser] section it should contain a line saying:

Maiser:          Maiser   # 'Username' of mail server account

If that line is missing there will apparently not be any Sender: header added to messages delivered to a list.

You could alternatively try to catch the Comment: header that's added to list messages instead, but that is not covered by the standard header rules and will require a regular expression rule. The header reads "Comments: Originally To: list_name", so the rule set could be:

If header "F" contains "person" LogicalAnd ""
If not expression headers matches "Comments: Originally To: list_name*" LogicalAnd ""
If header "T" contains "list_name" Forward "other_person" 

/Rolf 

[/quote]

I do have that line in MERCURY.INI and I assure you (after looking

at hundreds of QCF and QDF files) "Sender" and "maiser" do not appear

in any of them.  But I did (finally) find something that works, by

keeping all but the first job (listname) from satisfying the rule:

If header "F" contains "personX" LogicalAnd ""

If not expression headers matches "*X-Autoforward*" LogicalAnd ""

If not expression headers matches "*X-listname*" LogicalAnd ""

If header "T" contains "stest" Forward "personY"

[quote user="Vincent Fatica"]

I do have that line in MERCURY.INI and I assure you (after looking

at hundreds of QCF and QDF files) "Sender" and "maiser" do not appear

in any of them.  But I did (finally) find something that works, by

keeping all but the first job (listname) from satisfying the rule:

If header "F" contains "personX" LogicalAnd ""

If not expression headers matches "*X-Autoforward*" LogicalAnd ""

If not expression headers matches "*X-listname*" LogicalAnd ""

If header "T" contains "stest" Forward "personY"

[/quote]

 P.S.  Does there exist an explanation of the codes and flags used by QCF and QDF files?  Such would be a great aid in figuring out the logic involved in queueing.

OK good. X-listname is another header that's normally added to list messages, so that should work as well. Do you need the X-Autoforward rule, though? I still just get one copy of the message when forwarding without it.

/Rolf 

There is a post on QCF flags in the Knowledgebase here.

/Rolf
 

[quote user="Rolf Lindby"]

OK good. X-listname is another header that's normally added to list messages, so that should work as well. Do you need the X-Autoforward rule, though? I still just get one copy of the message when forwarding without it.

/Rolf 

[/quote]

I think I tried X-listname alone and it wasn't sufficient (hard to keep track of all my experimentation).