These release notes support V4.7.0 of the ptx®/TCP/IP software intended for use with NUMA-Q® systems. Read this document before you install and run this release of the ptx/TCP/IP software.
The following software products are prerequisites for the ptx/TCP/IP V4.7.0 software product:
DHCP allows for configuration of hosts and provides a mechanism for assigning network addresses to hosts on a network. DHCP follows a client-server model, where a designated host, the DHCP server, allocates network addresses (from a pool of IP addresses it maintains) and provides configuration parameters to dynamically configure hosts (known as DHCP clients) on a network.
DHCP supports three mechanisms for IP address allocation. In "manual allocation," the network administrator assigns the IP address and the client uses DHCP to retrieve the same from the DHCP server. In "automatic allocation," DHCP assigns a permanent IP address to a client. In "dynamic allocation," DHCP allocates an IP address to the client for a limited period of time, known as the "lease time," after which the client relinquishes the use of that address, enabling the DHCP server to allocate the address to another client, if need be. Using the DHCP protocol enables a client system to configure its network interfaces without manual intervention. It also allows for efficient use of available IP addresses, since an IP address can be reused by another system, once the client system using it currently is done with it.
The DHCP client supplied with the ptx/TCP/IP distribution allows for configuring multiple interfaces on a single client system (on the same network or on different networks). It also allows for the client to work on networks where the server does a network directed broadcast instead of the usual all-one's broadcast.
The RFCs which are supported by this implementation are:
RFC 2131 - Dynamic Host Configuration Protocol (DHCP)
RFC 2132 - DHCP options and BOOTP Vendor Extensions
For details on the usage of the DHCP client, see the dhclient(1M) man page.
The client supports the following command-line options:
dhclient [ -p port ] [ -d ] [ if0 [ ... ifN] ] [ -r if0 ...ifN ]
For further details and a more complete description, see dhclient(1M).
The behavior of the DHCP client can be configured (changing protocol timing parameters, specifying interfaces to be configured, specifying protocol options to be requested from the DHCP server, default values for certain options, etc.) by using the /var/tcp/dhcpc/dhclient-conf file. The DHCP client reads this file on startup to get the list of all the interfaces and also the configuration parameters specified. The list of supported configurable parameters, the keywords to be used, their syntax and semantics, along with the usage are mentioned in the dhclient.conf(4) man page.
The DHCP client can use the /var/tcp/dhcpc/dhclient-conffile to specify a list of protocol options used in configuring the host on that network and also to let the host know of various services available for its use. The entire list of options supported, their syntax and semantics, and usage are discussed in the dhcp-options(4) and dhclient.conf(4) man pages.
The DHCP client periodically invokes the network configuration script /var/tcp/dhcpc/dhclient-script to set each interface's initial configuration prior to requesting an address, to test the address once it has been offered, or to set the interface's final configuration once a lease has been acquired. It is also called to set a pre-defined lease, if the client fails to receive any lease from the server and also when it finds no valid lease to use. The client invokes dhclient-script with a list of environment variables corresponding to the network parameters provided by the server or those specified in the configuration file. This script currently takes care of configuring the interface with an appropriate IP address and netmask, adding default routes, adding static routes, adding IP aliases, making appropriate entries in /etc/resolv.conf, setting the hostname, etc. Also, this script provides hooks to customize the behavior of the script according to user requirements or site specific requirements. The hooks provided, the different times when the client invokes this script, and the list of variables passed and their syntax are described in detail in the dhclient-script(4) man page.
The ptx/ADMIN TCP/IP menus allow you to tag an interface with the DHCPC tag (through the Expert Interface Configuration menus). Tagging an interface with this tag causes the system to invoke the DHCP client for that interface so that the interface is configured dynamically.
An interface tagged with theDHCPC tag through the menu interface will have the tag name in the tag field of the interface record in the ifnets file.
/etc/ifconfigall has been modified to recognize a new tag, DHCPC. On seeing an interface in the ifnets file with this tag, it invokes the DHCP client for that interface, so that an address is configured dynamically for that interface. See also "Changes to /etc/ifconfigall" later in this document.
The "media" and the "medium" parameters mentioned in the man page for dhclient.conf(4) are for those systems that support the setting of different media types through ifconfig (like 10ase5/AUI and 10baseT/UTP). ptx/TCP/IP does not support this feature of ifconfig.
If, while starting dhclient, you receive the error "pass_args_to: connect failed - Connection refused," check whether the file /var/tcp/dhcpc/dhcpc.socket exists. If it exists and no other dhclient process is running, remove the file and try invoking the client again.
When the user invokes the DHCP client multiple times, any client that is started after the first client, which is currently running, will pass the interface arguments to the first client and exit. The first client will configure the interface that was passed to it.
The client will periodically delete the information it holds for those interfaces which are being dynamically configured if the interface is detached from the system. The client scans its interface list once every 12 hours (this value is non-configurable), looking for interfaces which are down and have been detached.
If the client is invoked without any interface arguments when another client is already running, then nothing happens (i.e., except for -r <0...IFN> and the interface arguments themselves, when the -r option is not used, the rest of the command-line options are ignored when the client is invoked a second time).
Deleting a dynamically assigned IP address of an interface (using ifconfig) does not take care of stopping the DHCP protocol on that interface. Instead, it results in a situation where the client thinks that the address is still assigned. Later on, when the client tries to renew the same address again after the lease expiry time, it would fail to get the same address. This will cause the client to try and configure that interface with another new IP address.
For more information about dhcpc, refer to Chapter 3 of the ptx/TCP/IP Administration Guide.
ptx/TCP/IP V4.7.0 supports the Internet Message Access Protocol, Rev 4 (IMAP4), which accesses electronic mail or bulletin board messages that are kept on a (possibly shared) mail server. The IMAP server code is derived from University of Washington's IMAP-4.6 code base.
For more information, refer to Chapter 7 of the ptx/TCP/IP Administration Guide.
ptx/TCP/IP now supports filtering of IP packets and creation of IPSec tunnels using IETF IPSec working group standard Internet protocols. Commands for creating and manipulating filters and tunnels are listed below:
Filters:
Tunnels:
Statistics:
These commands are compatible with AIX Version 4.3.3 commands of the same names and also support import and export data files generated on AIX machines. For more information, refer to Chapter 8 of the ptx/TCP/IP Administration Guide and/or the manual entries for the individual commands.
ATTENTION DYNIX/ptx supports only the AIX manual tunnel type and does not support all encryption algorithms available in AIX.
The /etc/init.d/netservers file contains the following commented-out lines necessary for re-installation of tunnels and filters automatically on reboot. These lines must be uncommented on systems making use of filters and/or tunnels. Note also that netservers has multiple links, which must reflect the changes also, if not edited in place.
# # uncomment to use filters # #if [ -f /usr/etc/mkfilt ]; then # /usr/etc/mkfilt -v 4 -u -i & /bin/echo ' ipfiltering\c' #fi # # uncomment to use IPSec tunnels # #if [ -f /usr/etc/mktun ]; then # /usr/etc/mktun -v 4 -i & /bin/echo ' ipsec\c' #fi
This release of ptx/TCP/IP supports BIND 8.2.2-P5. The version of BIND distributed by earlier releases of ptx/TCP/IP is BIND 4.9.7. BIND 8.2.2-P5 introduces many new features, includes many security bug fixes, and has an entirely different syntax for the configuration file. This release of ptx/TCP/IP supports both BIND 8.2.2-P5 and BIND 4.9.7.
BIND 8.2.2-P5 supports the following new features:
ATTENTION For the purposes of this document, the term "server" refers to a BIND 8.2.2-P5 server, unless otherwise explicitly mentioned.
Configuration file. The default configuration file is /etc/named.conf (in the earlier versions it is /etc/named.boot).
The syntax of the statements in this file is completely different. See the man page for named.conf(4) for more details on the syntax of the configuration file.
IP address based access control. With access lists (see "acl" statement), the server can choose to serve or not serve the queries, zone transfer requests, and dynamic update requests received from a machine. The access lists are based on IP addresses.
It is also possible to specify access control on a zone-by-zone basis. By default, all the requests will be served.
Flexible, categorized logging system. Though the logging system is the same as older versions, the new name server gives you control over logging (see "logging" statement).
DNS Change Notification (RFC 1996). In the earlier versions (BIND 4.9.7 and pre-BIND 4.9.7), it is the secondary name server (if any) that queries the primary name server for the changes in a DNS zone data.
Because a primary server can notice the changes to zone data, a primary server can immediately NOTIFY (inform) its secondaries that some change has occurred. The secondary server responds to the primary and proceeds just as if the refresh timer had expired. BIND 8.2.2-P5 supports this feature.
The older secondary servers that do not support NOTIFY will respond with a Not Implemented (NOTIMP) error.
By default, this feature is enabled (see the "notify" substatement of the "zone" statement to enable/disable this feature).
DNS Dynamic Update (RFC 2136). The server permits authorized remote hosts to add or delete resource records from a zone. The server has to be primary for that zone; if the server is a secondary, it will forward the update request "upstream" to its primary server(s). If they, in turn, are secondaries for the zone, they will also forward the update upstream.
The authorization is based on IP addresses.
By default, dynamic updates to authorized zones are not allowed (see the "allow-update" substatement of the "zone" statement; this substatement enables the feature).
It is possible to create updates manually with the command-line program /usr/etc/nsupdate (see the man page for nsupdate(1M)).
The server no longer forks for outbound zone transfers.
DNSSEC (DNS Security Extensions) Support (RFC 2065). DNSSEC provides data origin authentication and data integrity checking through the use of digital signatures.
ATTENTION New record types (KEY, SIG, NXT) are introduced to support DNSSEC. Please see http://www.acmebw.com/papers/dnssec.pdf for more information on DNSSEC and new record types introduced for DNSSEC.
TSIG (Transaction SIGnatures). This feature makes the transactions (messages) between the servers and the resolvers secure. This is useful for DNS dynamic updates also.
ATTENTION DNSSEC may not be efficient here because the resolver has to obtain the DNSSEC related records for every query (since resolver does not cache information). Also, verifying DNSSEC signatures is CPU intensive. This may prove impractical, since many resolvers may be running on slow machines.
See the following link for more information on TSIG:
http://www.nai.com/nai_labs/asp_set/network_security/dns_secure_paper.asp
IXFR Support (RFC 1995). With this feature, secondary name servers do not have to transfer entire zone data after a change; only the change(s) can now be transferred. (The older form of transferring all the data is called AXFR.)
By default, this feature is disabled in the client side (in named-xfer). It is advisable not to enable this feature at all, as the code contains serious bugs which cause memory leaks and data corruption.
Forward Zones. This feature allows an administrator to specify which name servers to forward queries to in certain zones (see the "forward" and "forwarders" substatements of the "zone" statement).
RRset Ordering. It is now possible to configure the RRset (records attached to the same domain name with the same class and type) ordering (see the "rrset-order" substatement of the "options" statement for more information).
New Negative Caching Support (RFC 2308). If an authoritative name server responds to a query with an answer that says the domain name or data type in the query does not exist, the local name server will temporarily cache that information too.
In BIND 4.9.x, the TTL for negatively cached information is fixed at 10 minutes. With the newer version, the last field of a zone's SOA record becomes the negative caching TTL (note that in the earlier versions of BIND this field specified the default TTL for the records without any explicit TTL value).
Because of the new negative caching support, a new directive, $TTL, is introduced to specify the default TTL for the records. The TTL value can be specified in symbolic form (for example, $TTL 1h30m).
Support for multiple virtual name servers.
Maximum number of zones is 65536.
Apart from these major features, the server supports various options (see the "options" statement for those options and details).
The following new APIs are available:
resolver functions
res_ninit, res_nisourserver, fp_resstat, res_npquery,
res_hostalias,res_nquery, res_nsearch, res_nquerydomain,
res_nmkquery, res_nsend,res_nupdate, res_nmkupdate,
res_nclose, res_nsendsigned, res_findzonecut, p_nquery,
res_update
inet functions
inet_cidr_ntop, inet_cidr_pton
tsig functions
ns_sign, ns_sign_tcp, ns_sign_tcp_init, ns_verify,
ns_verify_tcp, ns_verify_tcp_init, ns_find_tsig
See the man pages for more information on these functions.
ATTENTION Currently, a primary name server is called "master" and a secondary name server is called "slave."
This section details the changes in BIND from 4.9.7.
The "transfer" directive of the older BIND version is not supported in 8.2.2-P5. The older version of BIND can be used in case the "transfer" directive is required.
Configuration file syntax change. In the older BIND version, each line in the configuration file specified some configuration information. The configuration information cannot be continued on subsequent lines. The first field of each line is called a "directive."
With the newer version, the configuration information can extend into multiple lines, referred together as a "statement."
The following example gives the BIND 4.9.7 "directives" and their equivalents in BIND 8.2.2-P5 in the form of "statements":
Older configuration file:
directory /usr/local/named
primary eng.sequent.com db.eng
primary 95.138.in-addr.arpa db.138.95
primary 0.0.127.in-addr.arpa db.127.0.0
secondary elm.sequent.com 138.95.105.56 db.elm
cache . db.cache
The equivalent in BIND 8.2.2-P5:
options { directory "/usr/local/named"; }; zone "eng.sequent.com" in { type master; file "db.eng"; }; zone "95.138.in-addr.arpa" in { type master; file "db.138.95"; }; zone "0.0.127.in-addr.arpa" in { type master; file "db.127.0.0"; }; zone "elm.sequent.com" in { type slave; file "db.elm"; masters { 138.95.105.56; }; }; zone "." in { type hint; file "db.cache"; };
Options statement: The directory specified after "directory" (in this case, /usr/local/named), is specified under the keyword "options" in the substatement "directory" and it is enclosed within double quotes. Notice the semicolon after the directory name, the braces and the other semicolon after the closing brace.
1st zone statement: Notice the keyword "in" (for internet). Also the directive "primary" is mapped to "type master;" substatement. "eng.sequent.com" is the domain name and the associated file is db.eng.
4th zone statement: "type slave;" substatement specifies that the server is a secondary server. "masters" substatement specifies the primary server for the zone "elm.sequent.com". Notice the braces around the IP address and the semicolons after the IP address and the braces.
5th zone statement: The initial set of root nameservers is specified using a hint zone. When the server starts up, it uses the root hints to find a root nameserver and get the most recent list of root nameservers.
The following list specifies, for a particular directive, the location of the corresponding statement in the new configuration file:
Older version | Newer version |
directory | options statement, directory |
primary | zone statement, type master |
secondary | zone statement, type slave |
cache | zone statement, type hint |
forwarders | options statement, forwarders |
sortlist | options statement, sortlist |
include | include statement |
stub | zone statement, type stub |
options forward-only | options statement, forward |
options no-recursion | options statement, recursion |
options no-fetch-glue | options statement, fetch-glue |
options query-log | options statement, category queries |
options fake-iquery | options statement, fake-iquery |
limit transfers-in | options statement, transfers-in |
limit transfers-per-ns | options statement, transfers-per-ns |
limit datasize | options statement, datasize |
xfrnets | options statement, allow-transfer |
bogusns | server statement, bogus |
check-names | options statement, check-names |
The configuration file of the older version can be converted to that of the newer version using the shell script /usr/etc/named-bootconf (see the man page for named-bootconf(1M)). No changes are required in the data files.
named
ATTENTION Previously, the syntax "-p port#[/localport#]" was supported; the first port was that used when contacting remote servers and the second one was the service port bound by the local instance of NAMED. The current usage is equivalent to the old usage without the localport# specified; this functionality can be specified with the "listen-on" clause of the configuration file's "options" statement.
named-xfer
named-xfer -z zone_to_transfer -f db_file -s serial_no [-d debuglevel]
[-l debug_log_file] [-i ixfr_file] [-t trace_file] [-p port#]
[-S] namesever {[axfr] | [ixfr]}
The axfr or ixfr after name server address designates the type of zone transfer to perform. Use axfr for a full-zone transfer or ixfr for an incremental-zone transfer.
dig
resolver configuration file (/etc/resolv.conf )
No changes in nslookup, host and dnsquery.
By default, if the nameserver does not know the answer to a query, it will query other nameservers. The source port used for making queries to other nameservers will be a random unprivileged port (in the case of the earlier versions, the source port used was 53).
This might pose a problem for packet filtering firewalls if they were configured to rely on the earlier behavior. The nameserver can be configured to fall back on the earlier behavior by the following line:
option { query-source address * port 53;};
Because of the newer resolver option no-check-names, the earlier relaxation on hostname checking is removed.
If the user still wants the relaxation, then this resolver option should be used.
Note that BIND 4.9.7 is deprecated in favor of BIND 8.2.2-P5.
There are two versions of named and named-xfer (older BIND 4.9.7 as well as the new BIND 8.2.2-P5).
Selection of which name server daemon to use is controlled by the /usr/etc/named and /usr/etc/named-xfer symbolic links. By default, these links are created based on the installation type: for scratch ptx/TCP/IP installations, the symbolic links are made to named8 and named-xfer8 executables. For delta ptx/TCP/IP installations, the symbolic links are made to named4 and named-xfer4 (or left undisturbed if the symbolic links were already present).
As there is no change in the protocol, there will not be any interoperability issues between named8 and named4 primaries. The same is true for named8 primaries and named4 secondaries. The only drawback in these situations is that the new features of named8 cannot be utilized. Also, there will not be any issues with bind4 resolvers communicating with named8 servers (or bind8 resolvers talking to named4 servers).
The administrator is advised to familiarize himself/herself with the new features/configuration file syntax before using the newer version.
The meaning of the last field in an SOA record is changed (see "New Negative Caching Support" for more information) and a new directive $TTL is introduced to specify the default TTL for the records.
The BIND 4.9.7 server on this ptx/TCP/IP release now dumps its statistics if it receives a SIGILL signal. In the earlier ptx/TCP/IP releases, the corresponding signal was SIGIOT.
In the case of a "trusted-keys" statement, the domain name is not to be enclosed in double quotes. This is a deviation from the general syntax for specifying domain names in the configuration file.
DNSSEC: If a zone has delegations, change the "start" and "end" lines to begin with a semicolon in FINISH-PARENT (this file is generated by dnssigner for a zone with delegations). dnssigner outputs these lines starting with a #, which will cause syntax errors.
DNSSEC and SENDMAIL: In case the name server is configured for DNSSEC, be aware that the server might take a long time before it starts responding to queries as it has to cryptographically verify the data in the zone files. The larger the data, the more time it takes for the server to respond to queries.
In such a situation, sendmail logs the following error in syslog: gethostbyaddr(<ip_address>) failed.
This can result in mail services being affected until the time the nameserver starts responding to queries.
To avoid problems with sendmail in this case, add all the IP addresses configured on the system (along with the fully qualified domain names) in /etc/hosts, and make sure that /etc/nsswitch.conf contains "files."
You may see messages of this form in syslog:
syslog: gethostby*.getanswer: asked for "<hostname> IN A", got type "SIG"
This is because when a DNSSEC-aware name server is queried, it tries to return the corresponding SIG record(s) associated with the RRset.
Additional DNSSEC-related links:
http://www.nic-se.se/dnssec/
http://www.cairn.net/DNSSEC/
The following bugs were fixed in BIND 8.2.2-P5 and associated utilities in ptx/TCP/IP V4.7.0:
nslookup gives garbled output while printing SIG records.
named dumps core when queried for a SIG RR.
make res_nsearch() behave like res_search() of older versions.
(BIND 8.2.3 from Internet Software Consortium will include these fixes.)
This release of ptx/TCP/IP includes an upgraded version of Sendmail, V8.10.0.
Sendmail V8.10.0 is compliant with the following RFCs:
RFC821 (Simple Mail Transport Protocol) RFC822 (Internet Mail Headers Format) RFC1123 (Internet Host Requirements) RFC2045 (MIME) RFC1869 (SMTP Service Extensions) RFC1652 (SMTP 8BITMIME Extension) RFC1870 (SMTP SIZE Extension) RFC1891 (SMTPDelivery Status Notifications) RFC1892 (Multipart/Report) RFC1893 (Mail System Status Codes) RFC1894 (Delivery Status Notifications) RFC1985 (SMTP Service Extension for Remote Message Queue Starting) RFC2033 (Local Message Transmission Protocol) RFC2476 (Message Submission) RFC2554 (SMTP Service Extension for Authentication)
The following is a list of key new features and changes in behavior from the old Sendmail:
Sendmail will no longer open or forward the following files if present in unsafe (i.e., group or world writeable) directory paths:
:include:, class, ErrorHeader, Helpfile alias, maps, ServiceSwitchFile option file
For more information on this feature, please see the section below on turning off security checks.
Support multiple queue directories. To use multiple queues, supply a QueueDirectory option value ending with an asterisk. For example, /var/spool/mqueue/q* will use all of the directories or symbolic links to directories beginning with 'q' in /var/spool/mqueue as queue directories. Keep in mind the queue directory structure should not be changed while sendmail is running. Queue runs create a separate process for running each queue unless the verbose flag is given on a non-daemon run. New items are randomly assigned to a queue.
Support different directories for qf, df, and xf queue files; if subdirectories or symbolic links to directories of those names exist in the queue directories, they are used for the corresponding queue files. Keep in mind the queue directory structure should not be changed while sendmail is running.
MAIL.LOCAL: mail.local will be installed to have setuid root. Note that this is not necessary when using the new configuration file corresponding to this release of Sendmail, but is necessary for earlier configuration files. If Sendmail is being used with the new configuration file, it is advisable to have the setuid bit turned off on mail.local.
VACATION: Added vacation auto-responder. This utility returns a message to the sender of a message telling them that you are currently not reading your mail. The intended use is in a .forward file. For example, your .forward file might have the following line:
\eric, "|/usr/bin/vacation -a allman eric"
This would send messages to you (assuming your login name was eric) and reply to any messages for "eric" or "allman."
New option "ControlSocketName," which, when set, creates a daemon control socket. This socket allows an external program to control and query status from the running sendmail daemon via a named socket, similar to the ctlinnd interface to the INN news server. Access to this interface is controlled by the UNIX file permissions on the named socket and on most UNIX systems.
Entries in the alias file can be continued by putting a blackslash directly before the newline.
Sendmail will use /etc/mail/ for sendmail-related files. This affects the following files:
Old file name | New file name |
/etc/mail/sendmail.hf | /etc/mail/helpfile |
/usr/lib/sendmail.st | /etc/mail/statistics |
ForwardPath option. This is the same as the "J" option of Sendmail V8.8.
For compatibility with old configuration files, if no suboption is specified, all the timeouts marked with a "*" are set to the indicated value. All but those marked with a "**" apply to client SMTP.
File modes. The modes used for files depend on what functionality you want and the level of security you require. In many cases, sendmail does careful checking of the modes of files and directories to avoid accidental compromise. If you want to make it possible to have group-writable support files, you may need to use the DontBlameSendmail option to turn off some of these checks.
To suid or not to suid? Sendmail is normally installed setuid to root. At the point where it is about to exec(2) a mailer, it checks to see if the userid is zero (root); if so, it resets the userid and groupid to a default (set by the U=equate in the mailer line; if that is not set, the DefaultUser option is issued). This can be overriden by setting the S flag to the mailer for mailers that are trusted and must be called as root. However, this will cause mail processing to be accounted (using sa(8)) to root rather than to the user sending the mail.
If you do not make sendmail setuid to root, it will still run but you lose a lot of functionality and a lot of privacy, since you will have to make the queue directory world readable. You could also make sendmail setuid to some pseudo-user (e.g., create a user called "sendmail" and make sendmail setuid to that) which will fix the privacy problems but not the functionality issues. Also, this is not a guarantee of security: for example, root occasionally sends mail, and the daemon often runs as root. Note however that sendmail must run as root or the trusted user in order to create the SMTP listener socket.
A middle ground is to make sendmail setuid to root, but set the RunAsUser option. This causes sendmail to become the indicated user as soon as it has done the start up that requires root privileges (primarily, opening the SMTP socket). If you use RunAsUser, the queue directory (normally /var/spool/mqueue) should be owned by that user, and all files and databases (including user .forward files, alias files, :include: files, and external databases) must be readable by that user. Also, since sendmail will not be able to change it's uid, delivery to programs or files will be marked as unsafe, e.g., undeliverable, in .forward, aliases, and :include: files. Administrators can override this by setting the DontBlameSendmail option to the setting NonRootSafeAddr. RunAsUser is probably best suited for firewall configurations that don't have regular user logins.
Turning off security checks. Sendmail is very particular about the modes of files that it reads or writes. For example, by default it will refuse to read most files that are group writable on the grounds that they might have been tampered with by someone other than the owner; it will even refuse to read files in group-writable directories.
If you are very sure that your configuration is safe and you want sendmail to avoid these security checks, you can turn off certain checks using the DontBlameSendmail option. This option takes one or more names that disable checks. In the descriptions that follow, "unsafedirectory" means a directory that is writable by anyone other than the owner. The values are:
Assume that the chown system call is restricted to root. Since some versions of Unix permit regular users to give away their files to other users on some filesystems, sendmail often cannot assume that a given file was created by the owner, particularly when it is in a writable directory. You can set this flag if you know that file giveaway is restricted on your system.
When reading class files (using the F line in the configuration file), allow files that are in unsafe directories.
Prevent logging of unsafe directory path warnings for non-existent forward files.
Allow the file named in the ErrorHeader option to be in an unsafe directory.
Change the definition of "unsafe directory" to consider group-writable directories to be safe. World-writable directories are always unsafe.
Allow a .forward file that is in an unsafe directory to include references to programs and files.
Allow a :include: file that is in an unsafe directory to include references to program and files.
Allow the service switch file to be a link, even if the directory is writable.
Allow group- or world-writable directories if the sticky bit is set on the directory. Do not set this on systems which do not honor the sticky bit on directories.
Moving the Per-User Forward Files. Some sites mount each user's home directory from a local disk on their workstation, so that local access is fast. However, the result is that .forward file lookups are slow. In some cases, mail can even be delivered on machines inappropriately because of a file server being down. The performance can be especially bad if you run the automounter.
The ForwardPath (J) option allows you to set a path of .forward files. For example, the following configuration file line would first look for a file with the same name as the user's login in /var/forward.
0 ForwardPath=/var/forward/$u:$z/.forward.$w
If the file is not found (or is inaccessible), the file ".forward.machinename" in the user's home directory is searched.
If you create a directory such as /var/forward, it should be mode 1777 (that is, the sticky bit should be set). Users should create the files mode 644. Note that you must use the forwardfileinunsafedirpath and forwardfileinunsafedirpathsafe flags with the DontBlameSendmail option to allow .forward files in a world-writable directory. This might also be used as a denial of service attack (users could create .forward files for other users); a better approach might be to create /var/forwardmode 755 and create empty files for each user, owned by that user, mode 644. If you do this, you do not have to set the DontBlameSendmail options indicated above.
Send to Me Too Option. Beginning with version 8.10, sendmail includes by default the (envelope) sender in any list expansions. For example, if "matt" sends to a list that contains "matt" as one of the members, he will get a copy of the message. If the MeToo option is set to FALSE (in the configuration file or via the command line), this behavior is changed, i.e., the (envelope) sender is excluded in list expansions.
New Ruleset Hooks. A few extra rulesets are defined as "hooks" that can be defined to get special features. They are all named rulesets. The "check_*" forms all give accept/reject status; falling off the end or returning normally is an accept, and resolving to $#error is a reject. Many of these can also resolve to the special mailer $#discard; this accepts the message as though it were successful, but then discards it without delivery.
Kstorage macro HMessage-Id: $>CheckMessageId SCheckMessageId # Record the presence of the header R$* $:$(storage {MessageIdCheck} $@ OK$)$1 R<$+ @ $+> $@ OK R$* $#error $: 553 Header Error Scheck_eoh # Check the macro R$* $:<$&{MessageIdCheck}> # Clear the macro for the next message R$* $:$(storage {MessageIDCheck} $) $1 # Has a Message-Id:header R<$+> $@ OK # Allow missing Message-Id: from local mail R$* $:<$&{client_name}> R<> $@ OK R<$=w> $@ OK # Otherwise, reject the mail R$* $#error $: 553 Header Error
Keep in mind the Message-Id: header is not a required header and is not a guaranteed spam indicator. This ruleset is an example and should probably not be used in production.
O SmtpGreetingMessage=$?{if_name}${if_name}$|$j$
New class $={persistentMacros}
Set to the macros which should be saved across queue runs. Care should be taken when adding macro names to this class.
The mib2agt subagent provided in this release has the following changes:
The ifIndex MIB variable will show the information corresponding to the index value assigned by IP to the network device. Earlier, it used to index them arbitrarily from 1...n.
The information shown by the ifDescr MIB variable will contain a short description about the network device instead of the pathname that was displayed in the earlier versions.
Support for RFC1285, which is used to display information for FDDI boards on VME systems, has been removed. Only RFC1512 is now supported, which enables the display of information about FDDI PCI devices.
The default behavior of ifconfigall has changed. /etc/ifconfigall will no longer delete interfaces or addresses to sync up to configuration files unless the -f option is used. By default, /etc/ifconfigall will bring up any interface or address specified for the given run level in the configuration files /var/tcp/ifaddrs and /var/tcp/ifnets that is not already up.
The -f option is new and reproduces the old behavior of /etc/ifconfigall. Note that using the -f flag will delete or bring down an interface even if it has a tag of DHCP.
Usage: ifconfigall [-s] [-f] run_level
Using the -f flag will force a synchronization to the configuration files (/var/tcp/ifaddrs and /var/tcp/ifnets, by default). Any dynamically added interfaces and addresses not present in the configuration files (or different from the configuration files) will be removed.
The -s flag will display the commands that would normally have been executed, but will not actually run the commands. This behavior has not changed.
For more information, see the ifconfigall(1M) man page.
To install ptx/TCP/IP V4.7.0, refer to the DYNIX/ptx V4.6.0 and Layered Products Software Installation Release Notes.
ATTENTION If you are installing ptx/TCP/IP V4.7.0 over a previous version of ptx/TCP/IP, you need to perform the following steps to ensure a successful installation. If you are performing a scratch install, you can ignore the rest of this caution.
During the installation, you may need to modify the preview log for ptx/TCP/IP.
Carefully examine the CONFLICTS entries in the preview.log file that are generated by the ptx/INSTALL program. The default answers might not be what you want.
Files such as /etc/hosts, /etc/services/, and etc/hosts.equiv might have a value of REPLACE rather than SKIP. You will need to restore your original files after the installation or change REPLACE to SKIP for the CONFLICTS entries in the preview.log file during the installation to ensure that your host-specific custom files are preserved. Note that the files /etc/inetd.conf, /var/tcp/ifaddrs, /var/tcp/routetab, /etc/mail/sendmail.cf, and /etc/mail/aliases are always retained from the previous installation, regardless of their CONFLICT entries in the preview log.
ptx/TCP/IP replaces the /etc/services file. If ptx/CLUSTERS is also installed on your system, this action will remove the ptx/CLUSTERS information from the file. To retain the information, you must change the preview log entry for /etc/services from CONFLICT-REPLACE to CONFLICT-SKIP.
Upon installation of this release of ptx/TCP/IP, if an imap entry does not exist in /etc/inetd.conf, the following imap entry will be added to /etc/inetd.conf:
imap stream tcp nowait root /usr/etc/imapdSimilarly, if an imap entry does not exist in /etc/services, the following imap entry will be added to /etc/services:
imap 154/tcpAlso note that this changed in inetd.conf and services files will occur regardless whether you choose CONFLICT-SKIP or CONFLICT-REPLACE.
ATTENTION The reshd, ftpd, and rexecd distributed with this release are BSD-sockets based and not TLI implementations. reshd was a TLI implementation until ptx/TCP/IP V4.4.1. In ptx/TCP/IP V4.7.0, rexecd will be disabled by default. Upon installing ptx/TCP/IP V4.7.0, inetd.conf entries, such as
ftp tli tcp nowait root /usr/etc/ftpd ftpd
shell tli tcp nowait root /usr/etc/reshd reshd
exec tli tcp nowait root /usr/etc/rexecd rexecdwill be modified to the following:
ftp stream tcp nowait root /usr/etc/ftpd ftpd
shell stream tcp nowait root /usr/etc/reshd reshd
#exec stream tcp nowait root /usr/etc/rexecd rexecdAlso note that this change in inetd.conf will occur irrespective of choosing CONFLICT-SKIP or CONFLICT-REPLACE. The inetd.conf being replaced will be saved in /usr/options/tcp/inetd_conf/inetd.conf.
The following documentation is available on the line documentation CD or at http://webdocs.sequent.com/:
ptx/TCP/IP Overview
ptx/TCP/IP Administration Guide
ptx/TCP/IP Programming Manual
ptx/TCP/IP Sockets Manual
ptx/TCP/IP Kernel Error Messages
This section lists the following problem report summaries:
The numbers in parentheses identify the problems in the problem-tracking system.
(238069) Sendmail 8.8 could have problems qualifying host names.
(241358) Lack of support for IP_GET_IF_CONFIG ioctl broke COFF RPC.
(244679) routed needed to handle IP aliases better.
(246779) The ifconfig -a command was very slow on a cluster.
(253709) Adding a network route from the menu system could have caused the system to hang.
(253651) The sockmod streams module could have lost queued data on the close of a connection.
(253455) A possible root exploit in the new DHCP client has been plugged. CIAC Bulletin I-053: ISC DHCP Distribution.
(253397) A rare race condition between incoming packets and lock processing could have caused a self-deadlock panic.
(251921) /etc/netstat did not flush stdout on a SIGHUP, and could have lost data.
(253702) Deleting a route from the ptx/ADMIN menu system failed occasionally with the error "Bad value."
(252578) If a LAN device was reset while in a flow blocked state, it could remain blocked.
(252189) /etc/ifconfigall would not attach an interface even if present in /var/tcp/ifnets if no address was provided in /var/tcp/ifaddrs.
(252155) Overlapping interfaces names confused /etc/routed and led to a mismanagement of those routes.
(252061) /etc/netstat failed to display large routing tables.
(251764) A race condition in tcp timers led to a system panic.
(251503) /etc/syslogd did not use nonblocking writes, which led to a slow reader blocking other users of /etc/syslogd.
(251473) A race condition in the telnet streams module led to a system panic.
(251195) MTU path discovery failed to increase the MTU subsequently once the MTU was lowered.
(251040) The default behavior of /etc/ifconfigall was modified to increase support for dynamically allocated interfaces and addresses.
(250944) The system panicked if a remote host did not negotiate an MSS.
(250782) Some rare configurations resulted in a flood of arp messages filling /usr/adm/ktlog.
(250446) The PDC component generated a large volume of unnecessary warnings in the log file.
(248967) Sendmail support for 8Bit MIME has been made robust.
(248844) Adding a route from the ptx/ADMIN menu system failed due to a failure to match and locate the correct route.
(247018) The default case when configuring a device using the ptx/ADMIN menu for the protocol type is now NO SNAP instead of SNAP.
When routes are flushed while sending out packets over an IPSec tunnel, a rare race condition might cause the system to panic. When using IPSec tunnels, be extremely careful to first close connections before doing a route flush, or avoid flushing of routes if possible.
Multiple SYNs may not be unique if connection requests arrive while the system clock has not changed (the system clock has a 10-millisecond resolution).