Ftp Web Hosting - J2Ee Hosting Sun Java Developing Blog

Chapter 17 - Electronic Mail Electronic mail transport has been one of the most prominent uses of networking since the first networks were devised. Email started as a simple service that copied a file from one machine to another and appended it to the recipient’s mailbox file. The concept remains the same, although an ever-growing net, with its complex routing requirements and its ever increasing load of messages, has made a more elaborate scheme necessary. Various standards of mail exchange have been devised. Sites on the Internet adhere to one laid out in RFC-822, augmented by some RFCs that describe a machine-independent way of transferring just about anything, including graphics, sound files, and special characters sets, by email.105 CCITT has defined another standard, X.400. It is still used in some large corporate and government environments, but is progressively being retired. Quite a number of mail transport programs have been implemented for Unix systems. One of the best known is sendmail, which was developed by Eric Allman at the University of California at Berkeley. Eric Allman now offers sendmail through a commercial venture, but the program remains free software. sendmail is supplied as the standard mail agent in some Linux distributions. We describe sendmail configuration in Chapter 18, Sendmail. Linux also uses Exim, written by Philip Hazel of the University of Cambridge. We describe Exim configuration in Chapter 19, Getting Exim Up and Running. Compared to sendmail, Exim is rather young. For the vast bulk of sites with email requirements, their capabilities are pretty close. Both Exim and sendmail support a set of configuration files that have to be customized for your system. Apart from the information that is required to make the mail subsystem run (such as the local hostname), there are many parameters that may be tuned. sendmail’s main configuration file is very hard to understand at first. It looks as if your cat has taken a nap on your keyboard with the shift key pressed. Exim configuration files are more structured and easier to understand than sendmail’s. Exim, however, does not provide direct support for UUCP and handles only domain addresses. Today that isn’t as big a limitation as it once might have been; most sites stay within Exim’s limitations. However, for most sites, the work required in setting up either of them is roughly the same. In this chapter, we deal with what email is and what issues administrators have to deal with. Chapter 18 and Chapter 19 provide instructions on setting up sendmail and Exim and for the first time. The included information should help smaller sites become operational, but there are several more options and you can spend many happy hours in front of your computer configuring the fanciest features. Toward the end of this chapter we briefly cover setting up elm, a very common mail user agent on many Unixlike systems, including Linux. For more information about issues specific to electronic mail on Linux, please refer to the Electronic Mail HOWTO by Guylhem Aznar,106 which is posted to comp.os.linux.answers regularly. The source distributions of elm, Exim, and sendmail also contain extensive documentation that should answer most questions on setting them up, and we provide references to this documentation in their respective chapters. If you need general information on email, a number of RFCs deal with this topic. They are listed in the bibliography at the end of the book. What Is a Mail Message? A mail message generally consists of a message body, which is the text of the message, and special administrative data specifying recipients, transport medium, etc., like what you see when you look at a physical letter’s envelope. Read RFC-1437 if you don’t believe this statement! 106 Guylhem can be reached at guylhem@danmark.linux.eu.org.

received 1714 bytes in 1.802 seconds (951 bytes/) postmaster pablo (1994-05-28 17:15:46.66) received 57 bytes in 0.634 seconds (89 bytes/) postmaster pablo (1994-05-28 17:15:49.91) received 1898 bytes in 1.599 seconds (1186 bytes/) postmaster pablo (1994-05-28 17:15:51.67) received 65 bytes in 0.555 seconds (117 bytes/) postmaster pablo (1994-05-28 17:15:55.71) received 3217 bytes in 2.254 seconds (1427 bytes/) postmaster pablo (1994-05-28 17:15:57.31) received 65 bytes in 0.590 seconds (110 bytes/) The third file is Debug. Debugging information is written here. If you use debugging, make sure this file has protection mode 600. Depending on the debug mode you select, it may contain the login and password you use to connect to the remote system. If you have some tools around that expect your log files to be in the traditional format used by HDB-compatible UUCP implementations, you can also compile Taylor UUCP to produce HDB-style logs. This is simply a matter of enabling a compile-time option in config.h.

Your Modem Does Not Dial If your modem doesn’t indicate that the DTR line has been raised when uucico calls out, you might not have given the right device to uucico. If your modem recognizes DTR, check with a terminal program that you can write to the modem. If this works, turn on echoing with \E at the start of the modem chat. If the modem doesn’t echo your commands during the modem chat, check if your line speed is too high or low. If you see the echo, check if you have disabled modem responses or set them to number codes. Verify that the chat script itself is correct. Remember that you have to write two backslashes to send one to the modem. Your Modem Tries to Dial but Doesn’t Get Out Insert a delay into the phone number, especially if you have to dial a special sequence to gain an outside line from a corporate telephone network. Make sure you are using the correct dial type, as some telephone networks support only one type of dialing. Additionally, double check the telephone number to make sure it’s correct. Login Succeeds, but the Handshake Fails Well, there can be a number of problems in this situation. The output in the log file should tell you a lot. Look at what protocols the remote site offers (it sends a string Pprotlist during the handshake). For the handshake to succeed, both ends must support at least one common protocol, so check that they do. If the remote system sends RLCK, there is a stale lockfile for you on the remote system already connected to the remote system on a different line. Otherwise, ask the remote system administrator to remove the file. If the remote system sends RBADSEQ, it has conversation count checks enabled for you, but the numbers didn’t match. If it sends RLOGIN, you were not permitted to log in under this ID. Log Files and Debugging When compiling the UUCP suite to use Taylor-style logging, you have only three global log files, all of which reside in the spool directory. The main log file is named Log and contains all the information about established connections and transferred files. A typical excerpt looks like this (after a little reformatting to make it fit the page): uucico pablo -(1994-05-28 17:15:01.66 539) Calling system pablo (port cua3) uucico pablo -(1994-05-28 17:15:39.25 539) Login successful uucico pablo -(1994-05-28 17:15:39.90 539) Handshake successful (protocol ‘g’ packet size 1024 window 7) uucico pablo postmaster (1994-05-28 17:15:43.65 539) Receiving D.pabloB04aj uucico pablo postmaster (1994-05-28 17:15:46.51 539) Receiving X.pabloX04ai uucico pablo postmaster (1994-05-28 17:15:48.91 539) Receiving D.pabloB04at uucico pablo postmaster (1994-05-28 17:15:51.52 539) Receiving X.pabloX04as uucico pablo postmaster (1994-05-28 17:15:54.01 539) Receiving D.pabloB04c2 uucico pablo postmaster (1994-05-28 17:15:57.17 539) Receiving X.pabloX04c1 uucico pablo -(1994-05-28 17:15:59.05 539) Protocol ‘g’ packets: sent 15, resent 0, received 32 uucico pablo -(1994-05-28 17:16:02.50 539) Call complete (26 seconds) uuxqt pablo postmaster (1994-05-28 17:16:11.41 546) Executing X.pabloX04ai (rmail okir) uuxqt pablo postmaster (1994-05-28 17:16:13.30 546) Executing X.pabloX04as (rmail okir) uuxqt pablo postmaster (1994-05-28 17:16:13.51 546) Executing X.pabloX04c1 (rmail okir) The next important log file is Stats, which lists file transfer statistics. The section of Stats corresponding to the above transfer looks like this (again, the lines have been split to fit the page): postmaster pablo (1994-05-28 17:15:44.78)

Based on the type of port used (modem, TCP, or direct), uucico will compose a default list of protocols. For modem and direct connections, this list usually comprises i, a, g, G, and j. For TCP connections, the list is t, e, i, a, g, G, j, and f. You can override this default list with the protocols command, which may be specified in a system entry as well as a port entry. For instance, you might edit the port file entry for your modem port like this: port serial1 … protocols igG This will require any incoming or outgoing connection through this port to use i, g, or G. If the remote system does not support any of these, the conversation will fail. Troubleshooting This section describes what may go wrong with your UUCP connection and makes location suggestions to fix the error. Although these problems are encountered on a regular basis, there is much more that can go wrong than what we have listed. If you have a problem, enable debugging with -xall, and take a look at the output in Debug in the spool directory. The file should help you to quickly recognize the problem. It is often helpful to turn on the modem’s speaker when it doesn’t connect. With Hayes-compatible modems, you can turn on the speaker by adding ATL1M1 OK to the modem chat in the dial file. The first check should always be whether all file permissions are set correctly. uucico should be setuid uucp, and all files in /usr/lib/uucp, /var/spool/uucp, and /var/spool/uucppublic should be owned by uucp. There are also some hidden files in the spool directory which must be owned by uucp as well.104 When you’re sure you have the permissions of all files set correctly, and you’re still experiencing problems, you can then begin to take error messages more literally. We’ll now look at some of the more common errors and problems. uucico Keeps Saying “Wrong Time to Call” This probably means that in the system entry in sys, you didn’t specify a time command that details when the remote system may be called, or you gave one that actually forbids calling at the current time. If no call schedule is given, uucico assumes the system can never be called. uucico Complains That the Site Is Already Locked This means that uucico detects a lock file for the remote system in /var/spool/uucp. The lock file may be from an earlier call to the system that crashed or was killed. Another possible explanation is that there’s another uucico process sitting around that is trying to dial the remote system and has gotten stuck in a chat script, or stalled for some other reason. To correct this error, kill all uucico processes open for the site with a hangup signal, and remove all lock files that they have left lying around. You Can Connect to the Remote Site, but the Chat Script Fails Look at the text you receive from the remote site. If it’s garbled, you might have a speed-related problem. Otherwise, confirm that it really agrees with what your chat script expects. Remember, the chat script starts with an expect string. If you receive the login prompt and send your name, but never get the password prompt, insert some delays before sending it, or even in between the letters. You might be too fast for your modem. That is, files with names beginning with a dot. Such files aren’t normally displayed by the ls command.

case scenerio, quoting doubles the amount of data to be transmitted, although compression done by the hardware may compensate. Lines that can transmit arbitrary 8-bit characters are usually called 8-bit clean. This is the case for all TCP connections, as well as for most modem connections. Taylor UUCP 1.06 supports a wide variety of UUCP protocols. The most common of these are: g This is the most common protocol and should be understood by virtually all uucicos. It does thorough error checking and is therefore well suited for noisy telephone links. g requires an 8-bit clean connection. It is a packet-oriented protocol that uses a sliding-window technique. This is a bidirectional packet protocol, which can send and receive files at the same time. It requires a full-duplex connection and an 8-bit clean data path. It is currently understood by Taylor UUCP only. t This protocol is intended for use over a TCP connection or other truly error-free networks. It uses packets of 1,024 bytes and requires an 8-bit clean connection. e This should basically do the same as t. The main difference is that e is a streaming protocol and is thus suited only to reliable network connections. f This is intended for use with reliable X.25 connections. It is a streaming protocol and expects a 7-bit data path. 8-bit characters are quoted, which can make it very inefficient. G This is the System V Release 4 version of the g protocol. It is also understood by some other versions of UUCP. a This protocol is similiar to ZMODEM. It requires an 8-bit connection, but quotes certain control characters like XON and XOFF. Tuning the Transmission Protocol All protocols allow for some variation in packet sizes, timeouts, etc. Usually, the defaults work well under standard circumstances, but may not be optimal for your situation. The g protocol, for instance, uses window sizes from 1 to 7, and packet sizes in powers of 2 ranging from 64 through 4096. If your telephone line is usually so noisy that it drops more than 5 percent of all packets, you should probably lower the packet size and shrink the window. On the other hand, on very good telephone lines the protocol overhead of sending acknowledgments for every 128 bytes may prove wasteful, so you might increase the packet size to 512 or even 1,024. Most binaries included in Linux distributions default to a window size of 7 and 128-byte packets. Taylor UUCP lets you tune parameters with the protocol-parameter command in the sys file. For instance, to set the g protocol’s packet size to 512 when talking to pablo, you have to add: system pablo … protocol-parameter g packet-size 512 The tunable parameters and their names vary from protocol to protocol. For a complete list of them, refer to the documentation enclosed in the Taylor UUCP source. Selecting Specific Protocols Not every implementation of uucico speaks and understands each protocol, so during the initial handshake phase, both processes have to agree on a common one. The master uucico offers the slave a list of supported protocols by sending Pprotlist, from which the slave may pick one.

Anonymous UUCP If you want to provide anonymous UUCP access to your system, you first have to set up a special account for it as previously described. A common practice is to give the anonymous account a login name and a password of uucp. In addition, you have to set a few of the security options for unknown systems. For instance, you may want to prohibit them from executing any commands on your system. However, you cannot set these parameters in a sys file entry because the system command requires the system’s name, which you don’t have. Taylor UUCP solves this dilemma through the unknown command. unknown can be used in the config file to specify any command that can usually appear in a system entry: unknown remote-receive ~/incoming unknown remote-send ~/pub unknown max-remote-debug none unknown command-path /usr/lib/uucp/anon-bin unknown commands rmail This will restrict unknown systems to downloading files from below the pub directory and uploading files to the incoming directory below /var/spool/uucppublic. The next line will make uucico ignore any requests from the remote system to turn on debugging locally. The last two lines permit unknown systems to execute rmail; but the command path specified makes uucico look for the rmail command in a private directory named anon- bin only. This restriction allows you to provide some special rmail that, for instance, forwards all mail to the superuser for examination. This allows anonymous users to reach the maintainer of the system, but at the same time prevents them from injecting any mail to other sites. To enable anonymous UUCP, you must specify at least one unknown statement in config. Otherwise uucico will reject all unknown systems. UUCP Low-Level Protocols To negotiate session control and file transfers with the remote end, uucico uses a set of standardized messages. This is often referred to as the high-level protocol. During the initialization phase and the hangup phase these are simply sent across as strings. However, during the real transfer phase, an additional low-level protocol that is mostly transparent to the higher levels is employed. This protocol offers some added benefits, such as allowing error checks on data sent over unreliable links. Protocol Overview UUCP is used over different types of connections, such as serial lines, TCP, or sometimes even X.25; it is advantageous to transport UUCP within protocols designed specifically for the underlying network protocol. In addition, several implementations of UUCP have introduced different protocols that do roughly the same thing. Protocols can be divided into two categories: streaming and packet protocols. Protocols of the streaming variety transfer a file as a whole, possibly computing a checksum over it. This is nearly free of overhead, but requires a reliable connection because any error will cause the whole file to be retransmitted. These protocols are commonly used over TCP connections but are not suitable for use over telephone lines. Although modern modems do quite a good job at error correction, they are not perfect, nor is there any error detection between your computer and the modem. On the other hand, packet-oriented protocols split up the file into several chunks of equal size. Each packet is sent and received separately, a checksum is computed, and an acknowledgment is returned to the sender. To make this more efficient, sliding-window protocols have been invented, which allow for a limited number (a window) of outstanding acknowledgments at any time. This greatly reduces the amount of time uucico has to wait during a transmission. Still, the relatively large overhead compared to a streaming protocol makes packet protocols inefficient for TCP use, but ideal for telephone lines. The width of the data path also makes a difference. Sometimes sending 8-bit characters over a serial connection is impossible; for instance, the connection could go through a stupid terminal server that strips off the eighth bit. When you transmit 8-bit characters over a 7-bit connection, they have to be quoted on transmission. In the worst

Protecting Yourself Against Swindlers A major problem with UUCP is that the calling system can lie about its name; it announces its name to the called system after logging in, but the server doesn’t have any way to check it. Thus, an attacker could log into his or her own UUCP account, pretend to be someone else, and pick up that other site’s mail. This is particularly troublesome if you offer login via anonymous UUCP, where the password is made public. You must guard against this sort of impostor. The cure for this disease is to require each system to use a particular login name by specifying a called-login in sys. A sample system entry may look like this: system pablo … usual options … called-login Upablo The upshot is that whenever a system logs in and pretends it is pablo, uucico checks whether it has logged in as Upablo. If it hasn’t, the calling system is turned down, and the connection is dropped. You should make it a habit to add the called-login command to every system entry you add to your sys file. It is important that you do this for all systems in your sys file, regardless of whether they will ever call your site or not. For those sites that never call you, you should probably set called-login to some totally bogus user name, such as neverlogsin. Be Paranoid: Call Sequence Checks Another way to fend off and detect impostors is to use call sequence checks. These help you protect against intruders who somehow manage to find out the password with which you log into your UUCP system. When using call sequence checks, both machines keep track of the number of connections established so far. The counter is incremented with each connection. After logging in, the caller sends its call sequence number, and the receiver checks it against its own number. If they don’t match, the connection attempt is rejected. If the initial number is chosen at random, attackers will have a hard time guessing the correct call sequence number. But call sequence checks do more for you. Even if some very clever person should detect your call sequence number as well as your password, you will find out. When the attacker calls your UUCP feed and steals your mail, this will increase the feeds call sequence number by one. The next time you call your feed and try to log in, the remote uucico will refuse you, because the numbers don’t match anymore! If you have enabled call sequence checks, you should check your log files regularly for error messages that hint at possible attacks. If your system rejects the call sequence number the calling system offers, uucico will put a message into the log file saying something like, “Out of sequence call rejected.” If your system is rejected by its feed because the sequence numbers are out of sync, it will put a message in the log file saying, “Handshake failed (RBADSEQ).” To enable call sequence checks, add the following command to the system entry: # enable call sequence checks sequence true In addition, you have to create the file containing the sequence number itself. Taylor UUCP keeps the sequence number in a file called .Sequence in the remote site’s spool directory. It must be owned by uucp and must be mode 600 (i.e., readable and writeable only by uucp). It is best to initialize this file with an arbitrary, previously agreed-upon start value. A simple way to create this file is: # cd /var/spool/uucp/pablo # echo 94316 > .Sequence # chmod 600 .Sequence # chown uucp.uucp .Sequence Of course, the remote site has to enable call sequence checks as well and start by using exactly the same sequence number as you.

# pablo system pablo … forward uchile #################### # uchile system uchile … forward-to pablo The forward-to entry for uchile is necessary so that any files returned by it are actually passed on to pablo. Otherwise UUCP would drop them. This entry uses a variation of the forward command that permits uchile to send files only to pablo through seci, not the other way round. To permit forwarding to any system, use the special keyword ANY (capital letters required). Setting Up Your System for Dialing In If you want to set up your site for dialing in, you have to permit logins on your serial port and customize some system files to provide UUCP accounts, which we will cover in this section. Providing UUCP Accounts To begin with, you have to set up user accounts that let remote sites log into your system and establish a UUCP connection. Generally, you will provide a separate login name to each system that polls you. When setting up an account for system pablo, you might give it the username Upablo. There is no enforced policy on login names; they can be just about anything, but it will be convenient for you if the login name is easily related to the remote host name. For systems that dial in through the serial port, you usually have to add these accounts to the system password file /etc/passwd. It is good practice to put all UUCP logins in a special group, such as uuguest. The account’s home directory should be set to the public spool directory /var/spool/uucppublic; its login shell must be uucico. To serve UUCP systems that connect to your site over TCP, you have to set up inetd to handle incoming connections on the uucp port by adding the following line to /etc/inetd.conf:101 uucp stream tcp nowait root /usr/sbin/tcpd /usr/lib/uucp/uucico -l The -l option makes uucico perform its own login authorization. It prompts for a login name and a password just like the standard login program, but relies on its private password database instead of /etc/passwd. This private password file is named /etc/uucp/passwd and contains pairs of login names and passwords: Upablo IslaNegra Ulorca co’rdoba This file must be owned by uucp and have permissions of 600. Does this database sound like such a good idea that you would like to use it on normal serial logins, too? Well, in some cases you can. What you need is a getty program that you can tell to invoke uucico instead of /bin/login for your UUCP users.102 The invocation of uucico would look like this: /usr/lib/uucp/uucico -l -u user The -u option tells it to use the specified user name rather than prompting for it.103 To protect your UUCP users from callers who might give a false system name and snarf all their mail, you should add called-login commands to each system entry in the sys file. This is described in the next section. 101 Note that tcpd usually has mode 700, so that you must invoke it as user root, not uucp. tcpd is discussed in more detail in Chapter 12, Important Network Features. 102 Gert Doering’s mgetty is such a beast. It runs on a variety of platforms, including SCO Unix, AIX, SunOS, HP-UX, and Linux. 103 This option is not present in Version 1.04.

commands rmail rnews bsmtp File Transfers Taylor UUCP also allows you to fine-tune file transfers in great detail. At one extreme, you can disable transfers to and from a particular system. Just set request to no, and the remote system will not be able to either retrieve files from your system or send it any files. Similarly, you can prohibit your users from transferring files to or from a system by setting transfer to no. By default, users on both the local and the remote system are allowed to upload and download files. In addition, you can configure the directories that files may be copied to and from. Usually you will want to restrict access from remote systems to a single directory hierarchy, but still allow your users to send files from their home directory. Commonly, remote users are allowed to receive files only from the public UUCP directory /var/spool/uucppublic. This is the traditional place to make files publicly available, very much like FTP servers on the Internet.100 Taylor UUCP provides four different commands to configure the directories for sending and receiving files. They are: local-send, which specifies the list of directories a user may ask UUCP to send files from; local- receive, which gives the list of directories a user may ask to receive files to; and remote-send and remote-receive, which do the analogous for requests from a foreign system. Consider the following exam ple: system pablo … local-send /home ~ local-receive /home ~/receive remote-send ~ !~/incoming !~/receive remote-receive ~/incoming The local-send command allows users on your host to send any files below /home and from the public UUCP directory to pablo. The local-receive command allows them to receive files either to the world- writable receive directory in the uucppublic, or any world-writable directory below /home. The remote-send directive allows pablo to request files from /var/spool/uucppublic, except for files from the incoming and receive directories. This is signaled to uucico by preceding the directory names with exclamation marks. Finally, the last line allows pablo to upload files to incoming. A major problem with file transfers using UUCP is that it receives files only to directories that are world- writable. This may tempt some users to set up traps for other users. However, there’s no way to escape this problem outside of disabling UUCP file transfers altogether. Forwarding UUCP provides a mechanism to have other systems execute file transfers on your behalf. For instance, suppose your system has uucp access to a system called seci, but not to another system called uchile. This allows you to make seci retrieve a file from uchile for you and send it to your system. The following command would achieve this: $ uucp -r seci!uchile!~/find-ls.gz ~/uchile.files.gz This technique of passing a job through several systems is called forwarding. On your own UUCP system, you would want to limit the forwarding service to a few hosts you trust not to run up a horrendous phone bill by making you download the latest X11R6 source release for them. By default, Taylor UUCP prohibits forwarding altogether. To enable forwarding for a particular system, you can use the forward command. This command specifies a list of sites the system may request you to forward jobs to and from. For instance, the UUCP administrator of seci would have to add the following lines to the sys file to allow pablo to request files from uchile: #################### You may use a tilde (~) character to refer to the UUCP public directory, but only in UUCP configuration files; outside it usually translates to the user’s home directory.

system gmu address news.groucho.edu time Any port tcp-conn chat ogin: vstout word: clouseau The address command gives the IP address of the host or its fully qualified domain name. The corresponding port entry would read: port tcp-conn type tcp service 540 The entry states that a TCP connection should be used when a sys entry references tcp-conn, and that uucico should attempt to connect to the TCP network port 540 on the remote host. This is the default port number of the UUCP service. Instead of the port number, you may also give a symbolic port name to the service command. The port number corresponding to this name will be looked up in /etc/services. The common name for the UUCP service is uucpd. Using a Direct Connection Assume you use a direct line to connect your system vstout to tiny. Much like in the modem case, you have to write a system entry in the sys file. The port command identifies the serial port tiny is hooked up to: system tiny time Any port direct1 speed 38400 chat ogin: cathcart word: catch22 In the port file, you have to describe the serial port for the direct connection. A dialer entry is not needed because there’s no need for dialing: port direct1 type direct speed 38400 device /dev/ttyS1 Controlling Access to UUCP Features UUCP is quite a flexible system. With that flexibility comes a need to carefully control access to its features to prevent abuse, whether it be intentional or accidental. The primary features of concern to the UUCP administrator are remote command execution, file transfer, and forwarding. Taylor UUCP provides a means of limiting the freedom that remote UUCP hosts have in exercising each of these features. With careful selection of permissions, the UUCP administrator can ensure that the host’s security is preserved. Command Execution UUCP’s task is to copy files from one system to another and to request execution of certain commands on remote hosts. Of course, you as an administrator would want to control what rights you grant other systems — allowing them to execute any command they choose on your system is definitely not a good idea. By default, the only commands Taylor UUCP allows other systems to execute on your machine are rmail and rnews, which are commonly used to exchange email and Usenet News over UUCP. To change the set of commands for a particular system, you can use the commands keyword in the sys file. Similarly, you may want to limit the search path to just those directories containing the allowed commands. You can change the search path allowed for a remote host with the command-path statement. For instance, you may want to allow system pablo to execute the bsmtp command in addition to rmail and rnews:99 system pablo … bsmtp is used to deliver mail with batched SMTP.