This section points out some message logging and tracking techniques.
Snapshots of message traffic, and information on TCP/IP connections handled by the PMDF Service Dispatcher, are also available.
29.4.3.1 Identifying the source of incoming SMTP messages
The identtcp or identtcpnumeric channel
keyword when placed on your tcp_local channel causes PMDF to attempt an
IDENT query on incoming SMTP connections. If the sending system is
running an IDENT server, it will return to PMDF the SMTP sender's
identity for PMDF to insert in the Received: header PMDF constructs. If
the sending system is not running an IDENT server, PMDF will just use
the port number (port 25) and the sending system IP number or name.
While IDENT information, when available, is desirable to have, note
that unfortunately IDENT servers are not in particularly widespread
use. Performing an IDENT query is an extra step under the best of
circumstances and in the case of sending systems not running and IDENT
server if likely to incur a noticeable performance hit: increasingly
routers simply "black hole" attempted connections to ports
that they don't recognize and if this happens on an IDENT query, then
PMDF does not hear back until the connection times out (a TCP/IP
package controlled timeout, typically on the order of a minute or two).
With identtcpnumeric, PMDF uses the IDENT information (if
any) and the actual IP number of the sending system; with
identtcp, PMDF also attempts to translate the IP number to
a system name by performing a DNS reverse lookup. Thus
identtcpnumeric incurs slightly less overhead because it
does not do the DNS reverse lookup, and the actual IP number may
perhaps be considered somewhat more authoritative that the name
resulting from a DNS query. However, using the system name as with
identtcp may be considered more user-friendly.
Identifying information in Received: headers can assist in detecting spoofed e-mail and in holding the senders of such spoofed e-mail accountable. Note that user-friendly identifying information is a not insignificant feature: even a naive user may notice that a Received: header in a suspicious message contains an unexpected address, e.g., anonymous@SpoofersAreUs.edu, but only a fairly sophisticated user is liable to pay attention to any IP numbers showing up in Received: headers. So a choice between these keywords may be affected by whether you are looking to provide forewarning to users that they may have received spoofed e-mail, or whether you merely wish to preserve the identifying information for use in investigating cases of spoofed e-mail.
See Section 2.3.4.39 for more details on these channel keywords.
29.4.3.2 Logging messages passing through PMDF
The logging channel keyword causes PMDF write a log file
entry for each pass of a message through a PMDF channel; see
Section 2.3.4.84 for details. The LOG_CONNECTION PMDF option can be used
to cause PMDF to log TCP/IP connections, such as SMTP, POP, and IMAP
connections; such connection entries may either be included in the
regular PMDF message log file, or written to a separate file. See
Section 7.3.6 for discussion of the LOG_CONNECTION and
SEPARATE_CONNECTION_LOG options. Note that with logging turned on, the
cumulative mail.log file in the PMDF log directory will
continue to grow and grow; PMDF itself never does anything with this
log file and it is up to you to periodically write it to backup and
delete it, or truncate it, or whatever your site prefers; the same is
true for the connection.log file if TCP/IP connections are
logged separately. Section 32.1.1 has a further discussion of managing
the PMDF log files.
In addition to the base set of data logged when the
logging keyword is used, there are options to cause the
log output to include additional details, as discussed in
Section 29.4.3.2.1 below.
29.4.3.2.1 Extra logging detail
In addition to the base set of logging enabled via the
logging channel keyword, PMDF has options that cause
additional information to be included in the entries written to the
mail.log* files. Note that logging such additional
information tends to incur additional overhead.
In particular, setting LOG_MESSAGE_ID=1, LOG_CONNECTION=7, and LOG_FILENAME=1 in your PMDF option file may be of interest on a PMDF e-mail firewall. Logging the message ID makes it easier to find entries in the log file corresponding to a particular message, or to correlate different entries in the log file corresponding to a single message. Logging the SMTP client connection information can be useful to show just what system really sent the message to your PMDF firewall. Logging the process id also logs the thread id in the case of multithreaded channels; while the process ids themselves normally will be rather monotonous on a PMDF firewall system, being that of a Dispatcher Worker Process (for SMTP messages received) or a PMDF Process Symbiont process (for SMTP messages sent), having the process id and thread id logged is quite useful for correlating message entries with connection entries. Logging the filename can be useful if you wish to correlate log file entries with actual message files currently in the PMDF queue area.
Setting LOG_HEADER=1 may be of interest if you wish to save certain
message headers to the mail.log* files.
Additionally, setting LOG_USERNAME=1 on a PMDF firewall system ought generally to result in fairly monotonous extra information being logged, as the username would normally just be the username of the user who last started the PMDF Service Dispatcher. Enable this options if you wish to confirm that the username of processes enqueuing messages are as expected.
See Section 7.3.6 for more details on such logging options.
29.4.3.3 Snapshots of message traffic through PMDF
PMDF maintains channel counters based on the Mail Monitoring MIB, RFC
1566. These counters can provide "snapshots" of the state of
the PMDF queues and a feel for the volume of messages passing through
PMDF. See Chapter 32 for details.
29.4.3.4 Monitoring TCP/IP connections to the Dispatcher
The PMDF Service Dispatcher maintains statistics on connections it
handles, e.g., the number of recent SMTP connections and the
hosts from which the connections were made. See Section 11.7 for
details.