Unless you have turned off this option in your Preferences file, MailBounce will generate a "Diagnostics" file on each run. It is recommended that you skim through the diagnostics file after each run, as it contains important information on MailBounce's actions and performance -- including all errors encountered -- on each run. Thus, it is important to understand the contents of this file.

Let's take a look at the diagnostics file output. The first section of the diagnostics file is just the "header" -- it includes information on the MailBounce version, your registration information, compile-time array limits, and your key Preferences settings. It should be mostly self-explanatory.

Processing the Bounce File

The next section of the diagnostics file summarizes the actual bounce processing; it provides a description of all of the bounces that were recognized by the MailBounce Engine, and the action taken on each one. Shown below is the output from a sample diagnostics file:


    PROCESSING BOUNCE FILE ...
    MailBounce Engine v6.0

        16   * <russell@wconnect.com>

This says that at line number 16 in the bounce file, this address was recognized as a hard bounce, which is denoted by an asterisk (i.e., hard bounces will be marked by asterisks in the diagnostics file).

NOTE: A "line," in MailBounce parlance, is just a line in your bounce file. It is not the same as a "bounce message." Thus, if you opened the bounce file that was used to create these examples, and counted down 16 lines from the top of the file, you would find the bounce for the address shown above. (Note that MailBounce does its best to provide the exact line number in the file; however, the nature of certain bounce formats sometimes makes it very difficult to identify the exact line on which the bounce was identified. The line numbers are generally very close, though.)

Soft bounces, as shown below, have just a blank space next to them:

      1560     <cmiscg@crc.staffs.ac.uk>

Thus, at line 1560, the address shown above was found to have soft bounced.

Redirects are denoted as follows:

      2278   R <yvonne@natwest.email.com>
             = <gbnw4tb@ibmmail.com>

The first line shows the old address, and the second line shows the new address. If you are a Pro user, and have "automatic processing of redirected addresses" selected in your Preferences file, then the old address will be unsubscribed and the new address will be subscribed to your mailing list; both addresses will be entered into the appropriate BCC files (depending on your settings). Note that redirects are not tracked; instead, the address change is effected immediately.

If you are a Lite user, or a Pro user with automatic redirects processing turned off, then you will see an informational message in your diagnostics file in place of the redirects lines above:

    ************************************************************
    %MailBounce_Engine(I): INFORMATIONAL MESSAGE FOR OPERATOR
    This address has been redirected...
    Old Address: yvonne@natwest.email.com
    New Address: gbnw4tb@ibmmail.com
    ************************************************************

An Ignored address is denoted by a "pipe" symbol; the display will show whether the ignored address was a hard bounce, soft bounce, redirect, or unsub (a hard bounce and a soft bounce are shown in the following example):

      3563  |* <Tar@MED.MCCHORD.COM>
      3624  |  <m9545@mateng1.swan.uk>

Also, the MailBounce Engine has the ability to "upgrade" bounces automatically; that is, if it logs an address as a soft bounce, and later finds the same address in a hard bounce, it will "upgrade" the soft bounce to a hard bounce. When this occurs, MailBounce will denote the upgrade with a "+" sign:

     46002     <jsmit@noldus.com>
     46605  +* <jsmit@noldus.com>

In this case, user jsmit@noldus.com was found to have soft bounced at line 46002; however, at line 46605, the address was found to have hard bounced. The soft bounce was thus "upgraded" to a hard bounce.

Prior to adding an address into the bounce array, MailBounce checks to ensure that the address is not already present in the array. If it is, MailBounce notes the attempted add, but does not duplicate the entry (which would be a waste of potentially-important space). MailBounce denotes a duplicate address by placing a dash next to it:

      1805  -  <sanders@mail.prompt.ca>

In this case, the address that was already be present in the bounce array was marked as a soft bounce. Had it been a hard bounce, MailBounce would have placed an asterisk next to the dash:

     51290  -* <hussin@birun.erum.co.uk>

Of course, if it was already present in the array as a soft bounce, and was later found to have hard bounced, then a "+" sign would have used to denote that the address was upgraded from soft bounce to hard bounce (as shown above).

If the "process unsubscribes" option is activated, and an "unsubscribe" command is encountered within the bounce file, the address will be displayed with a "U" next to it:

      2553   U <Wittmann@omni.voicenet.com>

These addresses are not tracked, but are instead removed from your mailing list immediately. Note that processing unsubscribe requests is a Preferences option, and is disabled by default.

Finally, MailBounce will attempt to alert you to badly-formatted bounces that it cannot process. It will also try to establish the severity of the bounce (hard, soft, redirect, unsub); in cases in which it cannot establish severity, MailBounce will simply classify it as a "bad address" in a diagnostic statement, and will display the offending record (and its corresponding line number) so you can find it easily in the bounce file:

    %MailBounce_Engine(W): Unprocessed hard bounce at line 3748
    --Record: 550 dennis r. crowley... User unknown

NOTE: Most MailBounce error statements have VMS-style "severity codes" in them; this is a holdover from MailBounce versions 1-3, which were written for the VMS operating system. The codes are defined as follows:

  (F) Fatal error (processing is terminated)
  (E) Generic error (not necessarily fatal)
  (W) Warning (not an error -- more of an alert)
  (I) Informational message
  (S) Status message

The codes are useful when quickly skimming the diagnostics file for errors.

When MailBounce has finished processing the bounce file, it will display the total number of records (lines) processed, the number (and type) of bounces found, and the interim processing time:

  BOUNCE FILE PROCESSING COMPLETED:
    Total lines processed:     407914
    Total bounce messages:       1139
    Bounced addresses found:     1090
    Hard bounce count:            581
    Soft bounce count:            501
    Redirects count:                3
    Number of unsubscribes:         5

  Elapsed processing time: 00:00:42

MailBounce will then proceed to track your soft and hard bounces. We'll deal with soft-bounce tracking only, since hard-bounce tracking (if it has been activated) is identical.

Bounce Tracking

MailBounce will check each bounced address against the tracking file to see how many times it has bounced in the past; it will then compare all of the addresses against the bounce threshold to determine which ones need to me marked for deletion. When an address is marked for deletion, it is displayed with the total number of times that it has bounced on previous MailBounce runs (up to 23, which is the max that MailBounce can track) shown in brackets:

    The following bounces have exceeded the max-bounce interval:
        [ 5]  <ABRYU@drhc-hrdc.x400.gc.com>
        [ 3]  <turner@star.co.uk>

When it finishes processing, MailBounce will display the total number of defunct addresses found:

      76 soft-bounce addresses were marked for deletion.

Refer to the Bounce_Tracking file for more information on hard- and soft-bounce tracking.

Address Matching

The last step is address matching. In this stage, MailBounce reads in your subscriber list (also known as the "subscribers file" or "address file"), and compares each subscriber's address against the bounce addresses that have been marked for deletion. If a match is found, MailBounce will display it as an exact match, as shown below (these examples were selected from a processing run on a Lyris mailing list, so the server entries will be in Lyris format):

  wilsonn@wustl.edu (Nancy Wilson)
    EXACT MATCH (Hard Bounce):
        <wilsonn@wustl.edu>

In this case, the address from the subscriber list, shown on the top line, was exactly matched to the bounce address, shown on the bottom line. In addition, MailBounce informs you that this address was a hard bounce.

If an exact match cannot be found, MailBounce will [optionally] attempt to fuzzy match the address. In this case, addresses of the form "username@mailbox.domain.com" can be matched to addresses of the form "username@domain.com", "username@gateway.domain.com", etc.; for example:

  adrianv@cyber.mailgate.singnet.com.sg (Adrian V.)
    FUZZY MATCH (Soft Bounce):
        <adrianv@mbox2.singnet.com.sg>

Here, the subscriber's address (on the top line) was fuzzy matched to what would otherwise have been a difficult bounce address to match (on the bottom line). And if you've set the "fuzzy matching sensitivity" setting in the Preferences file to MEDIUM or HIGH, MailBounce will also display the "fuzziness" level of the match, as shown in the following two illustrations:

  Brett_Christensen@notes.tw.com (Brett Christensen, Sydney, Australia)
    FUZZY MATCH (Hard Bounce, Fuzziness Level is HIGH)
        <Brett_Christensen@twglobal.com>

  MSMITH/CSTA_00@atc.army.mil (Mike Smith, Aberdeen, Maryland)
    FUZZY MATCH (Soft Bounce, Fuzziness Level is MEDIUM)
        <OU=3DCSTA/OU=3D00/MSMITH@ns2.atc.army.mil>

Note that a single address in the subscriber list can match more than one bounce address -- e.g., it can match one bounce address exactly, and fuzzy match another address. In that case, both matches will be displayed:

  RAMAH@sys.soft.net (Rama, Bangalore, India)
    FUZZY MATCH (Soft Bounce, Fuzziness Level is LOW)
        <ramah@psd.soft.net>

    EXACT MATCH (Soft Bounce):
        <ramah@sys.soft.net>

MailBounce also checks the Ignored file whenever it fuzzy matches an address, since the fuzzy-matched format might be in the Ignored file, but the original format might not be. When MailBounce finds a fuzzy-matched address in the Ignored file, it displays a notification:

  *** jzotta@pipeline.com (Joe Zotta)
  ***   Fuzzy Match Found In Ignored File:
  ***     <jzotta@usa.pipeline.com> (ignored)

In this case, the subscriber's address (top) was in the Ignored file, and was fuzzy matched to the bounce shown on the bottom line -- which was not in the Ignored file. Checking the Ignored file on fuzzy matches ensures that MailBounce will not inadvertently unsubscribe an ignored address, even if the format is slightly different than the biounce address. Of course, you can use wildcards in Ignored addresses to help ensure that even unanticipated address formats are caught. For more information on Ignored addresses, refer to the Ignored file documentation.

Once the address-matching phase is complete, MailBounce will display all of the addresses that it was not able to match, along with a final tally of matched and unmatched addresses (and total processing time from the moment that MailBounce was launched):

  The following addresses were NOT matched:
      * <206.14.12.3@ultra1.dreams.com>
        <98brauk@cortland.cynic.org>
        <x7410@cadeta.usma.edu>
        <x7746@cadetb.usma.edu>

  ... end defunct-address processing section.


  FINAL TALLY ...

    Matched addresses:     53
        13 hard bounces and 35 soft bounces plus 1 unsubscribe and 4 redirects
        (Total of 47 addresses written to server file)

    Unmatched addresses:    4
         1 hard bounce and 3 soft bounces

    Total addresses:       57


  End of run: Sat Mar 15 13:27:44 1997
  Total processing time: 00:00:53

Note: When MailBounce displays its list of unmatched addresses, the left column contains a character denoting the type of bounce, using the same convention as was employed when processing the bounce file:

  [space] soft bounce
        * hard bounce
        U unsubscribe
        R redirect

Finally, note that there can be an apparent discrepancy between the number of matched addresses and the number of addresses written to the server file. This is because the count of matched addresses is the TOTAL count of matches -- exact matches and fuzzy matches -- which can overlap in some cases. For example, if one of your subscriber's addresses matches multiple bounce addresses (say, on both exact and fuzzy matches), the subscriber's address will be written to the server file only one time, but the total match count will include all of the matched bounces. It is not necessary to write the address to the server file more than once, since it needs to be unsubscribed only once.

It is strongly recommended that you briefly review the diagnostics file after each run, as it usually contains some very important and/or useful information. In addition, if there are any processing problems (e.g., if your copy of MailBounce Lite has expired), they will often be easily noted in a brief scan of the file.

The other files that are created -- the Summary file and the Error Log -- are described in the Preferences file description and in the MailBounce Functional Description document. However, these files should not be used as substitutes for the Diagnostics file, as they do not contain the same level of detail as the Diagnostics file.

Note that you will often be asked to provide your diagnostics file when reporting bugs or anomalous behavior. Thus, if you encounter any problems, be sure to save your diagnostics file!

If you have any questions or experience any problems, please feel free to contact Smart Mail Solutions for assistance.

[home]

[ReadMe]