1 files changed, 0 insertions, 135 deletions
diff --git a/contrib/bind/man/mailaddr.7 b/contrib/bind/man/mailaddr.7
deleted file mode 100644
index 9a69a4d..0000000
--- a/contrib/bind/man/mailaddr.7
+++ /dev/null
@@ -1,135 +0,0 @@
-.\" Copyright (c) 1983, 1987 The Regents of the University of California.
-.\" All rights reserved.
-.\"
-.\" Redistribution and use in source and binary forms are permitted
-.\" provided that the above copyright notice and this paragraph are
-.\" duplicated in all such forms and that any documentation,
-.\" advertising materials, and other materials related to such
-.\" distribution and use acknowledge that the software was developed
-.\" by the University of California, Berkeley.  The name of the
-.\" University may not be used to endorse or promote products derived
-.\" from this software without specific prior written permission.
-.\" THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
-.\" IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
-.\" WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
-.\"
-.\"	@(#)mailaddr.7	6.5 (Berkeley) 2/14/89
-.\"
-.TH MAILADDR @DESC_EXT_U@ "February 14, 1989"
-.UC 5
-.SH NAME
-mailaddr \- mail addressing description
-.SH DESCRIPTION
-Mail addresses are based on the ARPANET protocol listed at the end of this
-manual page.  These addresses are in the general format
-.PP
-		user@domain
-.PP
-where a domain is a hierarchical dot separated list of subdomains.  For
-example, the address
-.PP
-		eric@monet.berkeley.edu
-.PP
-is normally interpreted from right to left: the message should go to the
-ARPA name tables (which do not correspond exactly to the physical ARPANET),
-then to the Berkeley gateway, after which it should go to the local host
-monet.  When the message reaches monet it is delivered to the user ``eric''.
-.PP
-Unlike some other forms of addressing, this does not imply any routing.
-Thus, although this address is specified as an ARPA address, it might
-travel by an alternate route if that were more convenient or efficient.
-For example, at Berkeley, the associated message would probably go directly
-to monet over the Ethernet rather than going via the Berkeley ARPANET
-gateway.
-.SS Abbreviation.
-.PP
-Under certain circumstances it may not be necessary to type the entire
-domain name.  In general, anything following the first dot may be omitted
-if it is the same as the domain from which you are sending the message.
-For example, a user on ``calder.berkeley.edu'' could send to ``eric@monet''
-without adding the ``berkeley.edu'' since it is the same on both sending
-and receiving hosts.
-.PP
-Certain other abbreviations may be permitted as special cases.  For
-example, at Berkeley, ARPANET hosts may be referenced without adding
-the ``berkeley.edu'' as long as their names do not conflict with a local
-host name.
-.SS Compatibility.
-.PP
-Certain old address formats are converted to the new format to provide
-compatibility with the previous mail system.  In particular,
-.PP
-		user@host.ARPA
-.PP
-is allowed and
-.PP
-		host:user
-.PP
-is converted to
-.PP
-		user@host
-.PP
-to be consistent with the \fIrcp\fP(@CMD_EXT@) command.
-.PP
-Also, the syntax
-.PP
-		host!user
-.PP
-is converted to:
-.PP
-		user@host.UUCP
-.PP
-This is normally converted back to the ``host!user'' form before being sent
-on for compatibility with older UUCP hosts.
-.PP
-The current implementation is not able to route messages automatically through
-the UUCP network.  Until that time you must explicitly tell the mail system
-which hosts to send your message through to get to your final destination.
-.SS Case Distinctions.
-.PP
-Domain names (i.e., anything after the ``@'' sign) may be given in any mixture
-of upper and lower case with the exception of UUCP hostnames.  Most hosts
-accept any combination of case in user names, with the notable exception of
-MULTICS sites.
-.SS Route-addrs.
-.PP
-Under some circumstances it may be necessary to route a message through
-several hosts to get it to the final destination.  Normally this routing
-is done automatically, but sometimes it is desirable to route the message
-manually.  Addresses which show these relays are termed ``route-addrs.''
-These use the syntax:
-.PP
-		<@hosta,@hostb:user@hostc>
-.PP
-This specifies that the message should be sent to hosta, from there to hostb,
-and finally to hostc.  This path is forced even if there is a more efficient
-path to hostc.
-.PP
-Route-addrs occur frequently on return addresses, since these are generally
-augmented by the software at each host.  It is generally possible to ignore
-all but the ``user@domain'' part of the address to determine the actual
-sender.
-.SS Postmaster.
-.PP
-Every site is required to have a user or user alias designated ``postmaster''
-to which problems with the mail system may be addressed.
-.SS Other Networks.
-.PP
-Some other networks can be reached by giving the name of the network as the
-last component of the domain.  \fIThis is not a standard feature\fP and may
-not be supported at all sites.  For example, messages to CSNET or BITNET sites
-can often be sent to ``user@host.CSNET'' or ``user@host.BITNET'' respectively.
-.SH BUGS
-The RFC822 group syntax (``group:user1,user2,user3;'') is not supported
-except in the special case of ``group:;'' because of a conflict with old
-berknet-style addresses.
-.PP
-Route-Address syntax is grotty.
-.PP
-UUCP- and ARPANET-style addresses do not coexist politely.
-.SH SEE ALSO
-mail(@CMD_EXT@), sendmail(@SYS_OPS_EXT@);
-Crocker, D. H.,
-.ul
-Standard for the Format of Arpa Internet Text Messages,
-RFC822.