Rules that Create Loops
(Last modified: 04May2004)
This document (10051150) is provided subject to the disclaimer at the end of this document.
Rules that Create Loops
Novell GroupWise 5.5
Rules that create loops are possible, but fairly unlikely. Internally, within the GroupWise system, a loop existing (because of a rule) is stopped by an internal counter. GroupWise has a built in counter so that if a user creates a rule that causes a repeating process to occur, the program will automatically stop the loop after less than five repetitions of the message delivery, event, etc. However this can be circumvented and could still be a problem.
Here is how. When a message is sent via a gateway, SMTP to the Internet for example, the GroupWise counter may lose track of the message. If the message comes back to the user and starts some sort of a loop, because the internal counter is not functioning, this loop may continue and ultimately down the server or otherwise accumulate enough traffic to create threatening problems for the system to deal with.
Don't use two rules when one will do.
Do be aware of the potential for the problem to happen.
Be super careful when forwarding or replying to an Internet address, actually test any reply or forwarding rule activity. Observe that the rule does only what is expected - and do so before abandoning the system for the weekend. One can always disable a rule and stop the process if the loop is caught soon enough, but if an in-box has 35000 messages in it; or the post office server is down because the network volume is full; or if the message server has thousands of messages waiting to be delivered, it could be difficult or impossible to get into the GroupWise client software far enough to disable the rule after it had run for several hours, or over the weekend. Far better to test the rule and watch for a few minutes to see that what does actually happen is what was expected to happen when the rule was written.
Administrators of GWIA systems have a couple of other ways to break loops:
First, A feature has been added to the access control of the GWIA gateway, that lets the admin disable Rule Generated Messages. (GWIA details> access control tab > create, or edit class of service, > SMTP Outgoing > allow rule generated messages).
Note: Exceptions do not have any affect on the Allow Rule Generated Messages option. If a user needs to be able to send rule generated mail to the Internet, the Admin can create a new class of service that allows rule generated messages, and add only the users they want to the member list.
Second, GWIA(5.5) has added the ability to detect and mail-bombs. This feature can be used to determine the looping messages have the same fingerprint and reject the messages (see helpfile for more info on mail-bomb detection). The danger is that these expanding the time to be long enough to catch loops could make it take so long we start killing valid messages.
Lastly, if the problem has occurred where thousands of unwanted e-mail messages are in a GroupWise 5.2x or greater mailbox and the shear amount of items in the mailbox is making it very difficult for a user to delete the unwanted mail or even access their mailbox or the purging of such messages on the POA is causing the CPU utilization to shoot through the roof then an easy solution actually exists.
A new version of gwcheck can be run to selectively delete and purge unwanted mail messages with a particular subject line e.g. "John Doe is on Vacation" from a users mailbox. The operation is performed through a standalone copy of gwcheck that performs the deletion and the purge. The gwcheck doing the purge will not busy up the POA with the task of purging which may be a big benefit to CPU utilization. The operation can be accomplished by following the gwcheck instructions
1) User "Zippo" creates a rule that says: Anytime "Zippo" gets a message, forward the message to "Zippo."
In this case, the user Zippo is forwarding or replying to their internal post office address, the internal counter in GroupWise will return an error and stop this loop after just a few times. This counter should work across the GroupWise system.
2) If the user Zippo uses their own Internet address in the rule and has created a rule such that anytime Zippo@novell,com gets a mail message, and responds by replying or forwarding to Zippo@novell.com; there exists a potential for a serious problem.
3) A user in Hong Kong sets a rule that forwards all incoming messages to his partner in New York that has a subject line of "Important Joint Effort,"
the partner, knowing that they should BOTH be informed of all messages about this "Important Joint Effort" sets a similar rule that forwards the New York mail to the Hong Kong user.
In both of these cases, the internal counter of GroupWise cannot work, because when the outgoing message gets dropped off to the Internet, the internal loop-protection-counter within GroupWise never recognizes the resulting inbound message as coming from within the system, so it does not increment on that message - it instead treats it as a brand new message; the rule activates, sends the message back to the other user, etc. etc.... This disables all protection against loops happening. As you might imagine, with two users on opposite sides of the world, there are serious (and expensive) issues involved if this occurs.
In the case of Zippo, he has "created" his own problems. But, in the case of the Hong Kong - New York scenario, they are caught unawares by inadvertently setting up the same problem for themselves, and without knowing that it was going to happen.
The Origin of this information may be internal or external to Novell. Novell makes all reasonable efforts to verify this information. However, the information provided in this document is for your information only. Novell makes no explicit or implied claims to the validity of this information.
Any trademarks referenced in this document are the property of their respective owners. Consult your product manuals for complete trademark information.
- Document ID:
- Solution ID: NOVL3608
- Creation Date: 30Mar2000
- Modified Date: 04May2004
Did this document solve your problem? Provide Feedback