When we send an email to Israel, they do not receive it. We can receive theirs fine, both parties isp say there is no problem, however they still do not receive our mail. we can send and receive e-mails anywhere else in the world without a problem. the address in israel is valid as is ours, our problem is that we cannot find where the problem is occuring, is there any way to track the path of the mail, or can you suggest any other course of action?
the weird thing is one message got through today, and the rest didn`t but i couldn`t find any difference between the successfull message and the unreceived mail.
our connection is isdn, with mailtraq on the server and pegasus on the workstations, we have NT on the server and 95 or 98 on the various workstaions.
I`m sure you`ll agree this is a bit of a bugger, and I for the life of me can`t figure out what is going on.
Many thanks in advance for any advice that you feel is relevant.
This question was answered on July 14, 1999. Much of the information contained herein may have changed since posting.
Unfortunately we do not have any direct experience with the exact setup you have with Mailtraq and Pegasus The obvious question is are you sure you did not do anything different today when the email got through? Such as not using your address book and handtyping in the address? On the other side did they do anything different today? Below you will find some information about event logging from the Mailtraq web page, maybe this will help.
As Mailtraq is a very complex system, operating many tasks simultaneously, it is not viable to provide visual cues for everything it does It is also possible that you will want to examine a past event more closely in order to identify problems or ensure that events took place as expected
To solve these problems, Mailtraq provides a comprehensive event logging facility Mailtraq logs many different types of events: everything from transaction messages to mail routing decisions Every event is listed immediately in the on-screen Event Log, through the remote event logging service, and (optionally) on disk
Logging events is an essential part of system administration, often providing the only information to explain why something didn’t work correctly, and to help correct it You should enable the on-disk logging even if you don’t think it will be an issue, as it will always be after problems occur that you will need the valuable information the logging system provides
On-Disk Event Logging
This facility is configured in the Server properties (accessed from the Options menu in the Mailtraq Console)
Configuring the On-Disk Log (Server Properties Dialogue)
Event Log File
This is the base file name for the disk-based log If the ‘Single File’ logging method is chosen, then this will be the only file that will contain the log entries
The logging method refers to how the log entries are stored in the log files If you use the single file option, then the file will grow quickly and possibly consume an unnecessary amount of disk space
An alternative is to rotate the log entries between several files, providing a multi-stage history of past events
The Event Log Window
The Event Log window (available from the Actions menu in the Mailtraq Console) provides essentially the same information as the on-disk log, but on screen and catagorised It only shows the most recent events, and does not cover any events that took place before the last shutdown
The Event Log Window
At the top of the Event Log window are a set of toggle buttons that allow you to mask certain categories of event You can also open multiple log windows with the button and have a different mask for each window
Since the log is continuously being updated, you may have difficulty scrolling through the events while new entries are being added You can toggle the pause button to temporarily suspend the addition of new entries You can also copy the entire log to the Windows clipboard with the button
Some entries may be too long to display on the screen If you click on the entry, the entire text will be displayed at the bottom of the window
Mailtraq can periodically generate reports on a number of topics, and send them to specific people Each report is configured in a similar way
Configuring an Event Report
The following reports are available :—
This report includes details on every Internet dial-up, including the amount of time spent on-line and the purpose of the dial-up The report also provides a sum total of the on-line time for that period
This is configured in the Dialup properties in the Options menu
Delivery Failure Report
This report provides information on every delivery failure generated by Mailtraq because it was unable to successfully send a message The individual failure reports are returned to the message senders, but this report can be sent to an administrator summarising all the failures during the reporting period
This is configured in the Outgoing Mail properties in the Options menu
Mail Barring Report
This report contains details on every message that was refused based on the mail barring policy (in the Incoming Mailproperties — Options menu) The report also identifies the barring rule used The report is also configured in the Incoming Mail Policy
Mailing List Subscription Report
This report contains information of every mailing list subscription and unsubscription, including details on subscribers who were removed by the Address Check messages
The report is configured from the Mailing List Properties dialogue
Archive Requests Report
This report provides information on all the message requests made to the archive, and is configured in the Archive Properties dialogue
The Mailtraq Database
The Mailtraq Database contains all the Mailtraq files This includes the configuration, messages, articles, cache files, and so on In fact a Mailtraq installation is defined almost entirely by its database If you move the database to another machine, all the configuration will remain intact The only information stored outside the database is the user interface settings and the files (such as the log files) where the user has specified their location
Normally the database will be placed directly below the directory containing the Mailtraq program files However, if you wish to move the data to another location, you can specify the database path by changing its reference in the Windows Registry
Mailtraq uses the registry value:
to locate the database during startup The path stored in this registry value is the directory under which the ‘database’ directory can be found For example, if the registry value contained “c:\program files\mailtraq”, then the database would be stored in “c:\program files\mailtraq\database”
You can use the REGEDIT.EXE program (which is part of Windows) to edit the registry values
The files in the database should never be edited whilst Mailtraq is running You can, however, insert messages directly into the inbound message router by placing them in the database\mail\pending directory You must use the Mailtraq message format (described below)
You should avoid placing Mailtraq’s database on a network drive Firstly, network drives are almost always considerably slower, and Mailtraq will generate a large amount of network traffic while it is operating Secondly, if Mailtraq is started as a service it is likely to start before the network drives are available If Mailtraq is started before the network drives are ready, it will not be able to load successfully
Mailtraq Message Format
Throughout the database, messages will be stored by Mailtraq Essentially, the format is the combination of the message envelope and the message itself They always follow the same format:
The first line must begin with “FROM: ”, followed by the e-mail address of the sender
The second line must begin with “RCPT: ”, followed by the e-mail address of a recipient This line must be repeated once for every recipient of the message
After the message envelope, the message itself (header fields then body separated by a blank line) follows Here is an example :—
FROM: [email protected]
RCPT: [email protected]
RCPT: [email protected]
Subject: New Widget
From: John Smith <[email protected]>
To: Alex Johnson <[email protected]>
CC: Jane Simpson <[email protected]>
Date: Tue, April 07 1998 15:15:50 GMT
Have you got the new widget specification yet?
Note: do not edit the database files ending in ‘.AFV’ Although they appear use the standard message format, other files reference the precise position that each message starts at
Note: never access the files whilst Mailtraq is running — while accessing them you may prevent Mailtraq from writing to them, resulting in lost data
About the author
Posted by Ken Colburn of Data Doctors on July 14, 1999