| Previous | Contents | Index |
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 can
perhaps be considered somewhat more authoritative that the name
resulting from a DNS query. However, using the system name as with
identtcp can 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 can 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 can be affected by whether you are looking to provide
forewarning to users that they can have received spoofed e-mail, or
whether you merely want 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 can 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 can 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 want to correlate log file
entries with actual message files currently in the PMDF queue area.
Setting LOG_HEADER=1 can be of interest if you want 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 want 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.
| Previous | Next | Contents | Index |