Tải bản đầy đủ
[Appendix E] E.5 Sample Configurations

[Appendix E] E.5 Sample Configurations

Tải bản đầy đủ

[Appendix E] E.5 Sample Configurations

Chapter 10. Excerpts from the modified file are listed in this appendix and are heavily commented to make the modifications
more understandable. A full listing of the sendmail.cf file would consume 15 pages. Compare that to the listing of the m4 files
shown above.
The linux.smtp.cf file is not identical to the configuration file produced by m4, even when you follow the example in the
"Building a sendmail.cf with m4 Macros" section of Chapter 10. The configurations are similar but not identical. Use this text
as a general guide to the structure and function of configuration file. Don't expect the details to match your file exactly.
This excerpt shows the entire local information section because it is discussed extensively in Chapter 10:
#++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
# The V command defines the configuration syntax version level.
# Level 6 was supported by sendmail-8.7.5, which was the release
# of sendmail that came with Slackware 96 Linux 2.0. The vendor
# name Berkeley means that the standard syntax of the Berkeley
# distribution is supported.
#++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
# level 6 config file format
V6/Berkeley
#++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
#Like most sendmail configuration files, the first sections of the file
#contain the data that is most likely to require custom configuration.
#In this file, the section is titled "Local info". Note that we moved
#things around in this section to bring related items together. They
#don't really occur in this sequence in the linux.smtp.cf file.
#++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
##################
#
local info
#
##################
#++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
#If your host is known by more than one hostname, the multiple host
#names are defined in class "w", which contains all of the names for
#which your host will accept mail.
#++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Cwlocalhost
#++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
The j macro is correctly define by the system. No need to set it here.
#++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
# my official domain name
# ... define this only if sendmail cannot automatically determine
# your domain
#Dj$w.Foo.COM
#++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
#Class P is used to store pseudo domains. It is only used in this
#file to store a dot (.) used to identify canonical names. The dot
#(.) class, which is supposed to be used to identify canonical names,
#is not referenced anywhere else in the file.
#++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
CP.
# a class with just dot (for identifying canonical names)
C..

file:///C|/mynapster/Downloads/warez/tcpip/appe_05.htm (2 of 5) [2001-10-15 09:19:35]

[Appendix E] E.5 Sample Configurations

#++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
#Several different mail relay servers can be defined. We don't use any
#in this sample configuration. The L macro and the L class are only
#significant if relay servers are defined for handling "local" mail.
#++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
# "Smart" relay host (may be null)
DS
# who I send unqualified names to (null means deliver locally)
DR
# who gets all local email traffic ($R has precedence for unqualified names)
DH
# place to which unknown users should be forwarded
#Kuser user -m -a<>
#DLname_of_luser_relay
# class L: names that should be delivered locally, even if we have a relay
#CL root
#++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
#Sample K commands are included in the linux.smtp.cf file. Of these,
#only the dequote database is active. The others are commented out by
#default. The purpose of each of these databases is explained earlier
#in this appendix.
#++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
# Mailer table (overriding domains)
#Kmailertable dbm /etc/mailertable
# Domain table (adding domains)
#Kdomaintable dbm /etc/domaintable
# dequoting map
Kdequote dequote
#++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
#Several lines relate to address "masquerading". Macro M defines the
#hostname that should be used in place of the system's real hostname
#on outgoing mail. The M class defines other hostnames that should be
#converted to the macro M hostname. Class E defines usernames for which
#the hostname should not be converted to $M.
#++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
# class E: names that should be exposed as from this host, even if
# we masquerade
CE root
# class M: domains that should be converted to $M
#CM
# who I masquerade as (null for no masquerading) (see also $=M)
DMnuts.com
#++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
#We added this K command to define a database that we created that converts
#username to the user's real first and last names.
#++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
# define a database to map login names to firstname.lastname
Krealnames dbm /tmp/realnames

file:///C|/mynapster/Downloads/warez/tcpip/appe_05.htm (3 of 5) [2001-10-15 09:19:35]

[Appendix E] E.5 Sample Configurations

# operators that cannot be in local usernames (i.e., network indicators)
CO @ %
# my name for error messages
DnMAILER-DAEMON
#++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
#Macro Z contains the configuration file's version number. Modify it
#every time the file is updated. Keep a record of your modifications.
#++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
# R1.0 - modified for peanut by Craig
#
- cleaned up the comments in the local info section
# R1.1 - modified macro M to use nuts.com instead of the
#
hostname in outgoing mail
# R2.0 - added rule a to S11 & S31 to rewrite to first.last format
DZ8.7.3R2.0
In Chapter 10 we modified ruleset 94 to enable masquerading for envelope addresses.
###################################################################
### Ruleset 94 -- convert envelope names to masqueraded form
###
###################################################################
#++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
#To enable "envelop" address masquerading we "uncommented" the first line
#in this ruleset so that it now calls ruleset 93.
#++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
S94
R$+
$@ $>93 $1
R$* < @ *LOCAL* > $*
$: $1 < @ $j . > $2
The mailers do not usually require modification. However, in Chapter 10, we made some changes to the S rulesets of the
"smtp" mailer. We made changes to both ruleset 11 and ruleset 31.
#++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
#In Chapter 10 we added a single rule to the end of this ruleset to lookup
#the username in the "realnames" database we created and return the
#user's real first and last names.
#++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
#
# envelope sender rewriting
#
S11
R$+
$: $>51 $1
sender/recipient common
R$* :; <@>
$@
list:; special case
R$*
$: $>61 $1
qualify unqual'ed names
R$+
$: $>94 $1
do masquerading
# when masquerading convert login name to firstname.lastname
R$- < @ $M . > $*
$: $(realnames $1 $) < @ $M . > $2 user=>first.last
#
# envelope recipient rewriting
# also header recipient if not
#
S21
R$+
$: $>51
R$+
$: $>61

-masquerading recipients

$1
$1

file:///C|/mynapster/Downloads/warez/tcpip/appe_05.htm (4 of 5) [2001-10-15 09:19:35]

sender/recipient common
qualify unqual'ed names

[Appendix E] E.5 Sample Configurations

#++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
#In Chapter 10 we added a single rule to the end of this ruleset to look up
#the username name in the "realnames" database we created and return the
#user's real first and last names. This is the same modification made
#above. Often more than one ruleset is modified to add a single new
#feature.
#++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
#
# header sender and masquerading header recipient rewriting
#
S31
R$+
$: $>51 $1
sender/recipient common
R:; <@>
$@
list:; special case
# do special header rewriting
R$* <@> $*
$@ $1 <@> $2
pass null host through
R< @ $* > $*
$@ < @ $1 > $2
pass route-addr through
R$*
$: $>61 $1
qualify unqual'ed names
R$+
$: $>93 $1
do masquerading
# when masquerading convert login name to firstname.lastname
R$- < @ $M . > $*
$: $(realnames $1 $) < @ $M . > $2
user=>first.last

Previous: E.4 More
sendmail.cf
E.4 More sendmail.cf

TCP/IP Network
Administration
Book Index

Next: F. Selected TCP/IP
Headers
F. Selected TCP/IP Headers

[ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ]

file:///C|/mynapster/Downloads/warez/tcpip/appe_05.htm (5 of 5) [2001-10-15 09:19:35]

[Appendix F] Selected TCP/IP Headers

Previous: E.5 Sample
Configurations

Appendix F

Next: F.2 TCP Segment
Header

F. Selected TCP/IP Headers
Contents:
IP Datagram Header
TCP Segment Header
ICMP Parameter Problem Message Header
In Chapter 11, Troubleshooting TCP/IP , several references are made to specific TCP/IP headers. Those
headers are documented here. This is not an exhaustive list of headers; only the headers used in the
troubleshooting examples in Chapter 11 are covered:




IP Datagram Header, as defined in RFC 791, Internet Protocol
TCP Segment Header, as defined in RFC 793, Transmission Control Protocol
ICMP Parameter Problem Message Header, as defined in RFC 792, Internet Control Message Protocol

Each header is presented using an excerpt from the RFC that defines the header. These are not exact quotes; the
excerpts have been slightly edited to better fit this text. However, we still want to emphasize the importance of
using primary sources for troubleshooting protocol problems. These headers are provided here to help you
follow the examples in Chapter 11. For real troubleshooting, use the real RFCs. You can obtain your own
copies of the RFCs by following the instructions in Chapter 13, Internet Information Resources .

F.1 IP Datagram Header
This description is taken from pages 11 to 15 of RFC 791, Internet Protocol, by Jon Postel, Information
Sciences Institute, University of Southern California.
Internet Header Format
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service|
Total Length
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Identification
|Flags|
Fragment Offset
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live |
Protocol
|
Header Checksum
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
file:///C|/mynapster/Downloads/warez/tcpip/appf_01.htm (1 of 4) [2001-10-15 09:19:36]

[Appendix F] Selected TCP/IP Headers

|
Source Address
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Destination Address
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Options
|
Padding
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version:

4 bits

The Version field indicates the format of the internet header.
This document describes version 4.
IHL:

4 bits

Internet Header Length is the length of the internet header in 32
bit words. The minimum value for a correct header is 5.
Type of Service:

8 bits

The Type of Service indication the quality of service desired.
The meaning of the bits is explained below.
Bits 0-2:
Bit
3:
Bits
4:
Bits
5:
Bit 6-7:

Precedence.
0 = Normal Delay,
1 = Low Delay.
0 = Normal Throughput, 1 = High Throughput.
0 = Normal Reliability 1 = High Reliability.
Reserved for Future Use.

0
1
2
3
4
5
6
7
+-----+-----+-----+-----+-----+-----+-----+-----+
|
|
|
|
|
|
|
|
PRECEDENCE
| D | T | R | 0 | 0 |
|
|
|
|
|
|
|
+-----+-----+-----+-----+-----+-----+-----+-----+
Precedence
111
110
101
100
011
010
001
000

-

Network Control
Internetwork Control
CRITIC/ECP
Flash Override
Flash
Immediate
Priority
Routine

Total Length:

16 bits

Total Length is the length of the datagram, measured in octets
(bytes), including internet header and data.
Identification:

16 bits

file:///C|/mynapster/Downloads/warez/tcpip/appf_01.htm (2 of 4) [2001-10-15 09:19:36]

[Appendix F] Selected TCP/IP Headers

An identifying value assigned by the sender to aid in assembling
the fragments of a datagram.
Flags:

3 bits

Various Control Flags.

The Flag bits are explained below:

Bit 0: reserved, must be zero
Bit 1: (DF) 0 = May Fragment, 1 = Don't Fragment.
Bit 2: (MF) 0 = Last Fragment, 1 = More Fragments.
0
1
2
+---+---+---+
|
| D | M |
| 0 | F | F |
+---+---+---+
Fragment Offset:

13 bits

This field indicates where in the datagram this fragment belongs.
The fragment offset is measured in units of 8 octets (64 bits).
The first fragment has offset zero.
Time to Live:

8 bits

This field indicates the maximum time the datagram is allowed to
remain in the internet system.
Protocol:

8 bits

This field indicates the Transport Layer protocol that the data
portion of this datagram is passed to. The values for various
protocols are specified in the "Assigned Numbers" RFC.
Header Checksum:

16 bits

A checksum on the header only. Since some header fields change
(e.g., time to live), this is recomputed and verified at each
point that the internet header is processed. The checksum
algorithm is:
The checksum field is the 16 bit one's complement of the one's
complement sum of all 16 bit words in the header. For purposes
of computing the checksum, the value of the checksum field is
zero.
Source Address:

32 bits

The source IP address. See Chapter 2, Delivering the Data, for a
description of IP addresses.
Destination Address:

32 bits

file:///C|/mynapster/Downloads/warez/tcpip/appf_01.htm (3 of 4) [2001-10-15 09:19:36]

[Appendix F] Selected TCP/IP Headers

The destination IP address.
addresses.
Options:

See Chapter 2 for a description of IP

variable

The options may or may not appear in datagrams, but they must be
implemented by all IP modules (host and gateways). No options
were used in any of the datagrams examined in Chapter 11.

Previous: E.5 Sample
Configurations
E.5 Sample Configurations

TCP/IP Network
Administration
Book Index

Next: F.2 TCP Segment
Header
F.2 TCP Segment Header

[ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ]

file:///C|/mynapster/Downloads/warez/tcpip/appf_01.htm (4 of 4) [2001-10-15 09:19:36]

[Appendix F] F.2 TCP Segment Header

Appendix F
Selected TCP/IP Headers

Previous: F.1 IP Datagram
Header

Next: F.3 ICMP Parameter
Problem Message Header

F.2 TCP Segment Header
This description is taken from pages 15 to 17 of RFC 793, Transmission Control Protocol, by Jon Postel,
Information Sciences Institute, University of Southern California.
TCP Header Format
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Source Port
|
Destination Port
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Sequence Number
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Acknowledgment Number
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data |
|U|A|P|R|S|F|
|
| Offset| Reserved |R|C|S|S|Y|I|
Window
|
|
|
|G|K|H|T|N|N|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Checksum
|
Urgent Pointer
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Options
|
Padding
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
data
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Source Port:

16 bits

The source port number.
Destination Port:

16 bits

The destination port number.
Sequence Number:

32 bits

The sequence number of the first data octet (byte) in this segment
(except when SYN is present). If SYN is present the sequence
number is the initial sequence number (ISN) and the first data
octet is ISN+1.

file:///C|/mynapster/Downloads/warez/tcpip/appf_02.htm (1 of 3) [2001-10-15 09:19:36]

[Appendix F] F.2 TCP Segment Header

Acknowledgment Number:

32 bits

If the ACK control bit is set, this field contains the value of
the next sequence number the sender of the segment is expecting to
receive. Once a connection is established this is always sent.
Data Offset:

4 bits

The number of 32 bit words in the TCP Header. This indicates
where the data begins. The TCP header (even one including options)
is an integral number of 32 bits long.
Reserved:

6 bits

Reserved for future use.
Control Bits:
URG:
ACK:
PSH:
RST:
SYN:
FIN:

6

Must be zero.

single-bit values (from left to right):

Urgent Pointer field significant
Acknowledgment field significant
Push Function
Reset the connection
Synchronize sequence numbers
No more data from sender

Window:

16 bits

The number of data octets (bytes) the sender of this segment is
willing to accept.
Checksum:

16 bits

The checksum field is the 16 bit one's complement of the one's
complement sum of all 16 bit words in the header and text.
Urgent Pointer:

16 bits

This field contains the current value of the urgent pointer as a
positive offset from the sequence number in this segment. The
urgent pointer points to the sequence number of the octet
following the urgent data. This field is only be interpreted
in segments with the URG control bit set.
Options:

variable

Options may occupy space at the end of the TCP header and are a
multiple of 8 bits in length.

Previous: F.1 IP Datagram
Header

TCP/IP Network
Administration

Next: F.3 ICMP Parameter
Problem Message Header

file:///C|/mynapster/Downloads/warez/tcpip/appf_02.htm (2 of 3) [2001-10-15 09:19:36]