Ftp Web Hosting - J2Ee Hosting Sun Java Developing Blog

smtp 25/tcp # Simple Mail Transfer Protocol This defines the TCP port number that is used for SMTP conversations. Port number 25 is the standard defined by the “Assigned Numbers” RFC (RFC-1700). When run in daemon mode, Exim puts itself in the background and waits for connections on the SMTP port. When a connection occurs, it forks, and the child process conducts an SMTP conversation with the peer process on the calling host. The Exim daemon is usually started by invoking it from the rc script at boot time using the following command: /usr/sbin/exim -bd -q15m The -bd flag turns on daemon mode, and -q15m makes it process whatever messages have accumulated in the message queue every 15 minutes. If you want to use inetd instead, your /etc/inetd.conf file should contain a line like this: smtp stream tcp nowait root /usr/sbin/exim in.exim -bs Remember you have to make inetd re-read inetd.conf by sending it an HUP signal after making any changes.116 Daemon and inetd modes are mutually exclusive. If you run Exim in daemon mode, you should make sure to comment out any line in inetd.conf for the smtp service. Equivalently, when having inetd manage Exim, make sure that no rc script starts the Exim daemon. You can check that Exim is correctly set up for receiving incoming SMTP messages by telnetting to the SMTP port on your machine. This is what a successful connect to the SMTP server looks like: $ telnet localhost smtp Trying 127.0.0.1… Connected to localhost. Escape character is ‘^]’. 220 richard.vbrew.com ESMTP Exim 3.13 #1 Sun, 30 Jan 2000 16:23:55 +0600 quit 221 richard.brew.com closing connection Connection closed by foreign host. If this test doesn’t produce the SMTP banner (the line starting with the 220 code), check that you are either running an Exim daemon process or have inetd correctly configured. If that doesn’t reveal the problem, look in the Exim log files (described next) in case there is an error in Exim’s configuration file. If Your Mail Doesn’t Get Through A number of features are available for troubleshooting installation problems. The first place to check is Exim’s log files. On Linux systems they are normally kept in /var/log/exim/log and are named exim_mainlog, exim_rejectlog, and exim_paniclog. On other operating systems, they are often kept in /var/spool/exim/log. You can find out where the log files are by running the command: exim -bP log_file_path The main log lists all transactions, the reject log contains details of messages that were rejected for policy reasons, and the panic log is for messages related to configuration errors and the like. Typical entries in the main log are shown below. Each entry in the log itself is a single line of text, starting with a date and time. They have been split into several lines here in order to fit them on the page: 2000-01-30 15:46:37 12EwYe-0004WO-00 <= jack@vstout.vbrew.com H=vstout.vbrew.com [192.168.131.111] U=exim P=esmtp S=32100 id=38690D72.286F@vstout.vbrew.com 2000-01-30 15:46:37 12EwYe-0004WO-00 => jill D=localuser T=local_delivery 2000-01-30 15:46:37 12EwYe-0004WO-00 Completed 116 Use kill HUPpid, for which pid is the process ID of the inetd process retrieved from a ps listing.

Chapter 19 - Getting Exim Up and Running This chapter gives you a quick introduction to setting up Exim and an overview of its functionality. Although Exim is largely compatible with sendmail in its behavior, its configuration files are completely different. The main configuration file is usually called /etc/exim.conf or /etc/exim/config in most Linux distributions, or /usr/lib/exim/config in older configurations. You can find out where the configuration file is by running the command: $ exim -bP configure_file You may have to edit the configuration file to reflect values specific to your site. In most common configurations there isn’t a great deal to change, and a working configuration should rarely have to be modified. By default, Exim processes and delivers all incoming mail immediately. If you have relatively high traffic, you may instead have Exim collect all messages in the so-called queue, and process them at regular intervals only. When handling mail within a TCP/IP network, Exim is frequently run in daemon mode: at system boot time, it is invoked from /etc/init.d/exim113 and puts itself in the background, where it waits for incoming TCP connections on the SMTP port (usually port 25). This is beneficial whenever you expect to have a significant amount of traffic because Exim doesn’t have to start up for every incoming connection. Alternatively, inetd could manage the SMTP port and have it spawn Exim whenever there is a connection on this port. This configuration might be useful when you have limited memory and low mail traffic volumes. Exim has a complicated set of command-line options, including many that match those of sendmail. Instead of trying to put together exactly the right options for your needs, you can implement the most common types of operation by invoking traditional commands like rmailor rsmtp. These are symbolic links to Exim (or if they’re not, you can easily link them to it). When you run one of the commands, Exim checks the name you used to invoke it and sets the proper options itself. There are two links to Exim that you should have under all circumstances: /usr/bin/rmail and /usr/sbin/sendmail.114 When you compose and send a mail message with a user agent like elm, the message is piped to sendmailor rmail for delivery, which is why both /usr/sbin/sendmail and /usr/bin/rmail should point to Exim. The list of recipients for the message is passed to Exim on the command line.115 The same happens with mail coming in via UUCP. You can set up the required pathnames to point to Exim by typing the following at a shell prompt: $ ln -s /usr/sbin/exim /usr/bin/rmail $ ln -s /usr/sbin/exim /usr/sbin/sendmail If you want to dig further into the details of configuring Exim, you should consult the full Exim specification. If this isn’t included in your favorite Linux distribution, you can get it from the source to Exim, or read it online from Exim’s web site at http://www.exim.org/. Running Exim To run Exim, you must first decide whether you want it to handle incoming SMTP messages by running as a separate daemon, or whether to have inetd manage the SMTP port and invoke Exim only whenever an SMTP connection is requested from a client. Usually, you will prefer daemon operation on the mail server because it loads the machine far less than spawning Exim over and over again for each connection. As the mail server also delivers most incoming mail directly to the users, you should choose inetd operation on most other hosts. Whatever mode of operation you choose for each individual host, you have to make sure you have the following entry in your /etc/services file: 113 Other possible locations are /etc/rc.d/init.d and rc.inet2. The latter is common on systems using a BSD-style structure for system admini stration files in the /etc directory. 114 This is the new standard location of sendmail according to the Linux File System Standard. Another common location is /usr/lib/sendmail, which is likely to be used by mail programs that are not specially configured for Linux. You can define both filenames as symbolic links to Exim so that programs and scripts invoking sendmail will instead invoke Exim to do the same things. 115 Some user agents, however, use the SMTP protocol to pass messages to the transport agent, calling it with the -bs option.

# sendmail -bH The statistics will continue to grow until you purge them. You might want to periodically run the purgestat command to make it easier to search and find recent entries, especially if you have a busy site. You could put the command into a crontab file so it runs automatically, or just do it yourself occasionally.

Field Meaning msgsreg The number of messages rejected msgsdis The number of messages discarded Mailer The name of the mailer A sample of the output of the mailstats command is shown in Example 18.5. Example 18.5: Sample Output of the mailstats Command # /usr/sbin/mailstats Statistics from Sun Dec 20 22:47:02 1998 M msgsfr bytes_from msgsto bytes_to msgsrej msgsdis Mailer 0 0 0K 19 515K 0 0prog 3 33 545K 0 0K 0 0 local 5 88 972K 139 1018K 0 0 esmtp ============================================================= T 121 1517K 158 1533K 0 0 This data is collected if the StatusFile option is enabled in the sendmail.cf file and the status file exists. Typically you’d add the following to your sendmail.cf file: # status file O StatusFile=/var/log/sendmail.st To restart the statistics collection, you need to make the statistics file zero length: > /var/log/sendmail.st and restart sendmail. hoststat The hoststat command displays information about the status of hosts that sendmail has attempted to deliver mail to. The hoststat command is equivalent to invoking sendmail as: sendmail -bh The output presents each host on a line of its own, and for each the time since delivery was attempted to it, and the status message received at that time. Example 18.6 shows the sort of output you can expect from the hoststat command. Note that most of the results indicate successful delivery. The result for earthlink.net, on the other hand, indicates that delivery was unsuccessful. The status message can sometimes help determine the cause of the failure. In this case, the connection timed out, probably because the host was down or unreachable at the time delivery was attempted. Example 18.6: Sample Output of the oststat Command # hoststat ————–Hostname ———-How long ago ———Results——— mail.telstra.com.au 04:05:41 250 Message accepted for scooter.eye-net.com.au 81+08:32:42 250 OK id=0zTGai-0008S9-0 yarrina.connect.com.a 53+10:46:03 250 LAA09163 Message acce happy.optus.com.au 55+03:34:40 250 Mail accepted mail.zip.com.au 04:05:33 250 RAA23904 Message acce kwanon.research.canon.com.au 44+04:39:10 250 ok 911542267 qp 21186 linux.org.au 83+10:04:11 250 IAA31139 Message acce albert.aapra.org.au 00:00:12 250 VAA21968 Message acce field.medicine.adelaide.edu.au 53+10:46:03 250 ok 910742814 qp 721 copper.fuller.net 65+12:38:00 250 OAA14470 Message acce amsat.org 5+06:49:21 250 UAA07526 Message acce mail.acm.org 53+10:46:17 250 TAA25012 Message acce extmail.bigpond.com 11+04:06:20 250 ok earthlink.net 45+05:41:09 Deferred: Connection time The purgestat command flushes the collected host data and is equivalent to invoking sendmail as:

Managing the Mail Spool Mail is queued in the /var/spool/mqueue directory before being transmitted. This directory is called the mail spool. The sendmail program provides a means of displaying a formatted list of all spooled mail messages and their status. The /usr/bin/mailq command is a symbolic link to the sendmail executable and behaves indentically to: # sendmail -bp The output displays the message ID, its size, the time it was placed in the queue, who sent it, and a message indicating its current status. The following example shows a mail message stuck in the queue with a problem: $ mailq Mail Queue (1 request) –Q-ID—-Size——-Q-Time—————–Sender/Recipient———— RAA00275 124 Wed Dec 9 17:47 root (host map: lookup (tao.linux.org.au): deferred) terry@tao.linux.org.au This message is still in the mail queue because the destination host IP address could not be resolved. We can force sendmail to process the queue now by issuing the /usr/bin/runq command. The runq command produces no output. sendmail will begin processing the mail queue in the background. Forcing a Remote Host to Process its Mail Queue If you use a temporary dial-up Internet connection with a fixed IP address and rely on an MX host to collect your mail while you are disconnected, you will find it useful to force the MX host to process its mail queue soon after you establish your connection. A small perl program is included with the sendmail distribution that makes this simple for mail hosts that support it. The etrn script has much the same effect on a remote host as the runq command has on our own. If we invoke the command as shown in this example: # etrn vstout.vbrew.com we will force the host vstout.vbrew.com to process any mail queued for our local machine. Typically you’d add this command to your PPP ip-up script so that it is executed soon after your network connection is established. Analyzing Mail Statistics sendmail collects data on mail traffic volumes and some information on hosts to which it has delivered mail. There are two commands available to display this information, mailstats, and hoststat. mailstats The mailstats command displays statistics on the volume of mail processed by sendmail. The time at which data collection commenced is printed first, followed by a table with one row for each configured mailer and one showing a summary total of all mail. Each line presents eight items of information: Field Meaning M The mailer (transport protocol) number msgsfr The number of messages received from the mailer bytes_from The Kbytes of mail from the mailer msgsto The number of messages sent to the mailer bytes_to The Kbytes of mail sent to the mailer

rewrite: ruleset 199 returns: isaac < @ linux . org . au . > rewrite: ruleset 98 input: isaac < @ linux . org . au . > rewrite: ruleset 98 returns: isaac < @ linux . org . au . > rewrite: ruleset 198 input: isaac < @ linux . org . au . > rewrite: ruleset 95 input: < uucp-new : moria > isaac rewrite: ruleset 95 returns: $# uucp-new $@ moria $: isaac rewrite: ruleset 198 returns: $# uucp-new $@ moria $: isaac rewrite: ruleset 0 returns: $# uucp-new $@ moria $: isaac The results of this test indicate that the hostname was resolved, and that the message would still have been routed to our smart host. This proves that our LOCAL_NET_CONFIG definition works correctly and it handled both cases correctly. This test was also successful, so we can happily assume our configuration is correct and use it. Running sendmail The sendmail daemon can be run in either of two ways. One way is to have to have it run from the inetd daemon; the alternative, and more commonly used method is to run sendmail as a standalone daemon. It is also common for mailer programs to invoke sendmail as a user command to accept locally generated mail for delivery. When running sendmail in standalone mode, place the command in an rc file so it starts at boot time. The syntax used is commonly: /usr/sbin/sendmail -bd -q10m The -bd argument tells sendmail to run as a daemon. It will fork and run in the background. The -q10m argument tells sendmail to check its queue every ten minutes. You may choose to use a different queue to check time. To run sendmail from the inetd network daemon, you’d use an entry like: smtp stream tcp nowait nobody /usr/sbin/sendmail -bs The -bs argument here tells sendmail to use the SMTP protocol on stdin/stdout, which is required for use with inetd. The runq command is usually a symlink to the sendmail binary and is a more convenient form of: # sendmail -q When sendmail is invoked this way, it processes any mail waiting in the queue to be transmitted. When running sendmail from inetd you must also create a cron job that runs the runq command periodically to ensure that the mail spool is serviced periodically. A suitable cron table entry would be similar to: # Run the mail spool every fifteen minutes 0,15,30,45 * * * * /usr/bin/runq In most installations sendmail processes the queue every 15 minutes as shown in our crontab example, attempting to transmit any messages there. Tips and Tricks There are a number of things you can do to make managing a sendmail site efficient. A number of management tools are provided in the sendmail package; let’s look at the most important of these.

rewrite: ruleset 96 input: isaac < @ vale . vbrew . com > rewrite: ruleset 96 returns: isaac < @ vale . vbrew . com . > rewrite: ruleset 3 returns: isaac < @ vale . vbrew . com . > rewrite: ruleset 0 input: isaac < @ vale . vbrew . com . > rewrite: ruleset 199 input: isaac < @ vale . vbrew . com . > rewrite: ruleset 199 returns: isaac < @ vale . vbrew . com . > rewrite: ruleset 98 input: isaac < @ vale . vbrew . com . > rewrite: ruleset 98 returns: isaac < @ vale . vbrew . com . > rewrite: ruleset 198 input: isaac < @ vale . vbrew . com . > rewrite: ruleset 198 returns: $# smtp $@ vale . vbrew . com . / $: isaac < @ vale . vbrew . com . > rewrite: ruleset 0 returns: $# smtp $@ vale . vbrew . com . / $: isaac < @ vale . vbrew . com . > We can see that this test has directed the message to the SMTP mailer to be forwarded directly to the vale.vbrew.com host and specifies the user isaac. This test confirms that our LOCAL_NET_CONFIG definition works correctly. For this test to succeed, the destination hostname must be able to be resolved correctly, so it must either have an entry in our /etc/hosts file, or in our local DNS. We can see what happens if the destination hostname isn’t able to be resolved by intentionally specifying an unknown host: # /usr/sbin/sendmail -bt ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter

rewrite: ruleset 199 input: isaac rewrite: ruleset 199 returns: isaac rewrite: ruleset 98 input: isaac rewrite: ruleset 98 returns: isaac rewrite: ruleset 198 input: isaac rewrite: ruleset 198 returns: $# local $: isaac rewrite: ruleset 0 returns: $# local $: isaac This output shows us how sendmail processes mail addressed to isaac on this system. Each line shows us what information has been supplied to a ruleset or the result obtained from processing by a ruleset. We told sendmail we wished to use rulesets 3 and 0 to process the address. Ruleset 0 is what is normally invoked and we forced ruleset 3 because it is not tested by default. The last line shows us that the result of ruleset 0 does indeed direct mail to isaac to the local mailer. Next we’ll test mail addressed to our SMTP address: isaac@vstout.vbrew.com. We should be able to produce the same end result as our last example: # /usr/sbin/sendmail -bt ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter

otheruser@otherhost. You can think of this as an advanced mail alias feature, one that operates using not just the destination user, but also the destination domain. To configure the virtusertable feature, add the feature to your sendmail.mc configuration as shown: FEATURE(virtusertable) By default, the file containing the rules to perform translations will be /etc/mail/virtusertable. You can override this by supplying an argument to the macro definition; consult a detailed sendmail reference to learn about what options are available. The format of the virtual user table is very simple. The lefthand side of each line contains a pattern representing the original destination mail address; the righthand side has a pattern representing the mail address the virtual hosted address will be mapped to. The following example shows three possible types of entries: samiam@bovine.net colin sunny@bovine.net darkhorse@mystery.net @dairy.org mail@jhm.org @artist.org $1@red.firefly.com In this example, we are virtual hosting three domains: bovine.net, dairy.org, and artist.org. The first entry redirects mail sent to a user in the bovine.net virtual domain to a local user on the machine. The second entry redirects mail to a user in the same virtual domain to a user in another domain. The third example redirects all mail addressed to any user in the dairly.org virtual domain to a single remote mail address. Finally, the last entry redirects any mail to a user in the artist.org virtual domain to the same user in another domain; for example, julie@artists.org would be redirected to julie@red.firefly.com. Testing Your Configuration The m4 command processes the macro definition files according to its own syntax rules without understanding anything about correct sendmail syntax; so there won’t be any error messages if you’ve gotten anything wrong in your macro definition file. For this reason, it is very important that you thoroughly test your configuration. Fortunately, sendmail provides a relatively easy way of doing this. sendmail supports an “address test” mode that allows us to test our configuration and identify any errors. In this mode of operation, we invoke sendmail from the command line, and it prompts us for a ruleset specification and a destination mail address. sendmail then processes that destination address using the rules specified, displaying the output of each rewrite rule as it proceeds. To place sendmail into this mode, we invoke it with the -bt argument: # /usr/sbin/sendmail -bt ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter

Barring users from receiving mail If you have users or automated processes that send mail but will never need to receive it, it is sometimes useful to refuse to accept mail destined for them. This saves wasted disk-space storing mail that will never be read. The blacklist_recipients feature, when used in combination with the access_db feature, allows you to disable the receipt of mail for local users. To enable the feature, you add the following lines to your sendmail.mc file, if they’re not already there: FEATURE(access_db) FEATURE(blacklist_recipients) To disable receipt of mail for a local user, simply add his details into the access database. Usually you would use the ### entry style that would return a meaningful error message to the sender so they know why the mail is not being delivered. This feature applies equally well to users in virtual mail domains, and you must include the virtual mail domain in the access database specification. Some sample /etc/mail/access entries might look like: daemon 550 Daemon does not accept or read mail. flacco 550 Mail for this user has been administratively disabled. grump@dairy.org 550 Mail disabled for this recipient. Configuring Virtual Email Hosting Virtual email hosting provides a host the capability of accepting and delivering mail on behalf of a number of different domains as though it were a number of separate mail hosts. Most commonly, virtual hosting is exploited by Internet Application Providers in combination with virtual web hosting, but it’s simple to configure and you never know when you might be in a position to virtual host a mailing list for your favorite Linux project, so we’ll describe it here. Accepting mail for other domains When sendmail receives an email message, it compares the destination host in the message headers to the local host name. If they match, sendmail accepts the message for local delivery; if they differ, sendmail may decide to accept the message and attempt to forward it on to the final destination (See “The access database” earlier in this chapter for details on how to configure sendmail to accept mail for forwarding). If we wish to configure virtual email hosting, the first thing we need to do is to convince sendmail that it should also accept mail for the domains that we are hosting. Fortunately, this is a very simple thing to do. The sendmailuse_cw_file feature allows us to specify the name of a file where we store domain names for which sendmail accepts mail. To configure the feature, add the feature declaration to your sendmail.mc file: FEATURE(use_cw_file) The default name of the file will be /etc/mail/local-host-names for distributions using the /etc/mail/ configuration directory or /etc/sendmail.cw for those that don’t. Alternatively, you can specify the name and location of the file by overriding the confCW_FILE macro using a variation on: define(`confCW_FILE’,`/etc/virtualnames’) To stick with the default filename, if we wished to offer virtual hosting to the bovine.net, dairy.org, and artist. org domains, we would create a /etc/mail/local-host-names that looks like: bovine.net dairy.org artist.org When this is done, and assuming appropriate DNS records exist that point those domain names to our host, sendmail will accept mail messages for those domains as though they were destined for our real domain name. Forwarding virtual-hosted mail to other destinations The sendmailvirtusertable feature configures support for the virtual user table, where we configure virtual email hosting. The virtual user table maps incoming mail destined for some user@host to some