Looping messages means that there are messages in the transport that are looping between mailboxes or servers. Note that looping as a result of the product design was much more frequent in Exchange 2000 Server than it is in Exchange Server 2003. There are several things that can be done to figure this one out:

• Go to the server object in Exchange System Manager(ESM) and, on the Diagnostics Logging tab, turn up logging on:
       MSExchangeIS > Public Folder > Rules
       MSExchangeIS > Mailbox > Rules
  Making this chage will show you if there is a specific rule or rules that are firing often or repeatedly, which could lead to why e-mail is bouncing.
  
• Go to the server object in Exchange System Manager and, on the General tab, turn on Message Tracking if it is not turned on. If it was not turned on, after you do so, you should wait for a while to generate some activity in it. If the logging was already turned on, check the message tracking log. By default, the tracking logs are located in the following folder:
       [drive:]\Program Files\Exchsrvr\<servername>.log
  The General tab shows you the location of this file on computers running Exchange Server 2003. However, this information is not displayed on the General tab in Exchange 2000 Server but the default location is the same.
  The log files use the following naming format:
       <YEAR><MONTH><DAY>.log
  Therefore, the log called 20050131.log was created on January 31, 2005. A new log is created every day. If the server is a very busy server, the message tracking logs can get quite large.
  On clustered servers, the message tracking logs are located on the shared drive. Although there will be a folder on the local drive as on non-clustered servers, it will not contain any message tracking logs. There will be a folder with the name of <servername>.log on the shared drive. To connect to this folder over the network, use the following format:
       \\<Exchange Virtual Server name>\<servername>.log
  For a thorough analysis of these logs, please contact Microsoft Product Support Services. For a complete list of Microsoft Product Support Services telephone numbers and information about support costs, see the Microsoft Help and Support Contact Us Web site.
  

Public folder replication can obviously be a big generator of transaction logs. In most cases, public folder replication shows up as a problem in larger environments, where administrators might not be aware that someone else has created a replica for certain public folders on some other servers. The symptoms are that the transaction logs are growing and the size of the public folder store is growing too.

Note that because a public folder store might have a lot of white space in it, the actual size of the public folder store databases might not be increasing for some time even though the store holds more and more content.

If there are questions as to if the public folder store is a recipient of messages that are then causing transaction logs to be created, review the following:

• In the message tracking log file, check the "top recipients" and see if "<SERVERNAME>-IS@EXAMPLE.COM" (where example.com is the name of your domain) is one of the top recipients. This address is the default SMTP address of the MAPI public folder store on servers running Exchange 2000 Server and later. As the public folder replication messages are sent from store to store, it will be this address, rather than individual public folder addresses, that receive replication messages.
  
• Check to see if diagnostic logging is turned on. You can turn on diagnostics logging for the public folder replication messages to see if the server is getting hammered with those. To turn the logging on, go to the server object in Exchange System Manager and, on Diagnostics Logging, turn up the logging on:
       MSExchangeIS > Public Folder > Replication Incoming Messages (set it to Max).
  If the server is getting a lot of public folder replication messages, you will see a lot of MSExchangeIS Public Store events with event IDs of 3028 and 3030 (those will be the most common ones).
  

Caution:

If an administrator does realize that some erroneous public folder replication was triggered, he or she should just remove the replicas that they want to remove. They should not under any circumstances delete public folder replication messages from queues, because that causes problems later. The administrator has to "weather the storm" on this problem; alternatively, he or she can create separate connectors for system messages only and then schedule them to give their "normal" mailflow more room.

If the server is an open relay, there will be a lot of transaction logs. You will also usually see a lot of items in the Badmail folder. The key here is, of course, locking the server down so it is not an open relay anymore. There are several articles that talk about how to work on that, so that information will not be covered here. In particular, for information about mail relay issues, see Microsoft Knowledge Base article 895853, "How to troubleshoot mail relay issues in Exchange Server 2003 and in Exchange 2000 Server."

A large amount of messages in the Badmail folder is an indication of possible problems. Do note that, especially with Exchange Server 2003 Service Pack 1 (SP1) changes, it is possible to configure the Badmail folder to be emptied on a specific schedule, so that should be taken into the consideration too.

Scanning the M: drive / Exchange IFS will definitely cause the transaction logs to show up. File-level antivirus scanners, in most cases, modify the items they touch. As the M: drive is a virtual representation of your databases, those modifications are made to the database data. Therefore, there will be lots of transaction logs, usually generated over a short period of time (the duration of the scan). Databases will typically not increase in size as a result.

You will usually be able to see events in the Application log that give you clues that the M: drive and Exchange IFS are being scanned.

Events that may be logged if the M: drive is exposed and scanned may contain the following text:

Scan could not open file M:\DOMAIN.COM\MBX\alias\Inbox\somesubject.EML

Some antivirus software may scan files through the //./backofficestorage/ path. This path is still file level scanning, even though the M: drive is not exposed.

Needless to say, file level scanning needs to be stopped as soon as possible! For more information, see Microsoft Knowledge Base article 328841, "Exchange and antivirus software."

If Microsoft Entourage® is running on a Macintosh computer, and the user attempts to send an e-mail message that is larger than the mailbox send policy allows, the message stays in the Outbox and the transaction log files on the Exchange server grow at an alarming rate. To stop the transaction log from continuing to grow, the administrator must have the user delete the item out of the Outbox.

Essentially, what happens is that the Entourage client tries to send a message to the server over and over, thereby causing the increase in the transaction logs on the server. You will usually not see the database size increase with this problem.

This problem can occur on Exchange Server 2003 SP1 servers and Exchange 2000 Server SP3 and later servers.

For more information about this issue, see the following Microsoft Knowledge Base articles

• 889525, "An e-mail message stays in the Outbox and the Exchange Server 2003 transaction log files grow when an Entourage user tries to send a message that exceeds the size limit in Global Settings"
  
• 893624, "When you try to send a message in Entourage that exceeds the size limit in Global Settings, the e-mail message remains in the Outbox, and the transaction log files grow in Exchange 2000 Server"
  

Large amounts of move mailbox operations will cause a lot of transaction logs on both the server that the mailboxes are being moved from and the server that the mailboxes are being moved to. This happens because all of the mailbox messages are ultimately created on the target server and deleted on the source server. Both creations and deletions are logged transactions.

Additionally, certain ExMerge.exe operations create a lot of transaction logs. An example would be the archiving of e-mail into PST files (which deletes the messages from the Exchange store) or importing messages from PST files into the Exchange store (which creates messages in the Exchange store).

Merging mailboxes using the Exchange Server 2003 SP1 Recovery Storage Group functionality will also create transaction files.

Online maintenance performs a series of actions on the data within the Exchange Server database. Some of online maintenance tasks also generate transaction logs on the server. These transaction logs will typically only be created during the online maintenance period, but it is a good thing to keep this in mind as one of things that causes log file creation.