diff --git a/en_US.ISO8859-1/books/handbook/mail/chapter.sgml b/en_US.ISO8859-1/books/handbook/mail/chapter.sgml index a7dc55a75a..74bb9523cd 100644 --- a/en_US.ISO8859-1/books/handbook/mail/chapter.sgml +++ b/en_US.ISO8859-1/books/handbook/mail/chapter.sgml @@ -1,543 +1,807 @@ Bill Lloyd Original work by Jim Mock Rewritten by Electronic Mail Synopsis email electronic mail Electronic Mail, better known as email, is one of the most widely used forms of communication today. Millions of people use email every day, and chances are if you are reading this online, you fall into that category and probably even have more than one email address. Electronic Mail configuration is the subject of many System Administration books. If you plan on doing anything beyond setting up one mailhost for your network, you need industrial strength help. DNS Some parts of email configuration are controlled in the Domain Name System (DNS). If you are going to run your own DNS server, be sure to read through the files in /etc/namedb and man -k named. Using Electronic Mail POP IMAP There are five major parts involved in an email exchange. They are: the user program, the server daemon, DNS, a pop or IMAP daemon, and of course, the mailhost itself. The User Program This includes command line programs such as mutt, pine, elm, and mail, and GUI programs such as balsa, xfmail to name a few, and something more sophisticated like a WWW browser. These programs simply pass off the email transactions to the local mailhost, either by calling one of the server daemons available or delivering it over TCP. Mailhost Server Daemon mail server daemons sendmail mail server daemons postfix mail server daemons qmail mail server daemons exim This is usually sendmail (by default with FreeBSD) or one of the other mail server daemons such as qmail, postfix, or exim. There are others, but those are the most widely used. The server daemon usually has two functions—it looks after receiving incoming mail and delivers outgoing mail. It does not allow you to connect to it via POP or IMAP to read your mail. You need an additional daemon for that. Be aware that some older versions of sendmail have some serious security problems, however as long as you run a current version of it you should not have any problems. As always, it is a good idea to stay up-to-date with any software you run. Email and DNS The Domain Name System (DNS) and its daemon named play a large role in the delivery of email. In order to deliver mail from your site to another, the server daemon will look up the site in the DNS to determine the host that will receive mail for the destination. It works the same way when you have mail sent to you. The DNS contains the database mapping hostname to an IP address, and a hostname to mailhost. The IP address is specified in an A record. The MX (Mail eXchanger) record specifies the mailhost that will receive mail for you. If you do not have an MX record for your hostname, the mail will be delivered directly to your host. Receiving Mail email receiving Receiving mail for your domain is done by the mail host. It will collect mail sent to you and store it for reading or pickup. In order to pick the stored mail up, you will need to connect to the mail host. This is done by either using POP or IMAP. If you want to read mail directly on the mail host, then a POP or IMAP server is not needed. POP IMAP If you want to run a POP or IMAP server, there are two things you need to do: Get a POP or IMAP daemon from the ports collection and install it on your system. Modify /etc/inetd.conf to load the POP or IMAP server. The Mail Host mail host The mail host is the name given to a server that is responsible for delivering and receiving mail for your host, and possibly your network. + + + <application>sendmail</application> Configuration + + + sendmail + + + &man.sendmail.8; is the default Mail Transfer Agent (MTA) in + FreeBSD. sendmail's job is to accept + mail from Mail User Agents (MUA) and deliver it to the + approperate mailer as defined by its configuration file. + sendmail can also accept network + connections and deliver mail to local mailboxes or deliver it to + another program. + + sendmail uses the following + configuration files: + + + /etc/mail/access + + + /etc/mail/aliases + + + /etc/mail/local-host-names + + + /etc/mail/mailer.conf + + + /etc/mail/mailertable + + + /etc/mail/sendmail.cf + + + /etc/mail/virtusertable + + + + + + Filename + Function + + + + + + /etc/mail/access + + sendmail access database + file + + + + /etc/mail/aliases + + Mailbox aliases + + + + /etc/mail/local-host-names + + Lists of hosts sendmail + accepts mail for + + + /etc/mail/mailer.conf + + Mailer program configuration + + + + /etc/mail/mailertable + + Mailer delivery table + + + + /etc/mail/sendmail.cf + + sendmail master + configuration file + + + + /etc/mail/virtusertable + + Virtual users and domain tables + + + + + + <filename>/etc/mail/access</filename> + + The access database defines what host(s) or IP addresses + have access to the local mail server and what kind of access + they have. Hosts can be listed as , + , or simply passed + to sendmail's error handling routine with a given mailer error. + Hosts that are listed as , which is the + default, are allowed to send mail to this host as long as the + mail's final destination is the local machine. Hosts that are + listed as are rejected for all mail + connections. Hosts that have the option + for their hostname are allowed to send mail for any destination + through this mail server. + + + Configuring the <application>sendmail</application> + Access Database + + cyberspammer.com 550 We don't accept mail from spammers +FREE.STEALTH.MAILER@ 550 We don't accept mail from spammers +another.source.of.spam REJECT +okay.cyberspammer.com OK +128.32 RELAY + + + In this example we have five entries. Mail senders that + match the left hand side of the table are affected by the action + on the right side of the table. The first two examples give an + error code to sendmail's error + handling routine. The message is printed to the remote host when + a mail matches the left hand side of the table. The next entry + rejects mail from a specific host on the Internet, + another.source.of.spam. The next entry accepts + mail connections from a host + okay.cyberspammer.com, which is more exact than + the cyberspamer.com line above. More specific + matches override less exact matches. The last entry allows + relaying of electronic mail from hosts with an IP address that + begins with 128.32. These hosts would be able + to send mail through this mail server that are destined for other + mail servers. + + When this file is updated, you need to run + make in /etc/mail/ to + update the database. + + + + <filename>/etc/mail/aliases</filename> + + The aliases database contains a list of virtual mailboxes + that are expanded to other user(s), files, programs or other + aliases. Here is a few examples that can be used in + /etc/mail/aliases: + + + Mail Aliases + root: localuser +ftp-bugs: joe,eric,paul +bit.bucket: /dev/null +procmail: "|/usr/local/bin/procmail" + + + The aliases update matches the mailbox name on the left of + the colon, and will expand it to the target(s) on the right. + The first example simply expands the mailbox root to the mailbox + localuser, which is then looked up again in the aliases + database. If no match is found, then the message is delivered + to the local user localuser. The next example shows a mail + list. Mail to the mailbox ftp-bugs is expanded to the three + local mailboxes joe, eric, and paul. Note that a remote mailbox + could be specified as user@domain.com. The next example shows + writing mail to a file, in this case + /dev/null. The last example shows sending + mail to a program, in this case the mail message is written to + the standard input of + /usr/local/bin/procmail through a Unix + pipe. + + When this file is updated, you need to run + make in /etc/mail/ to + update the database. + + <filename>/etc/mail/local-host-names</filename> + + This is a list of hostnames &man.sendmail.8; is to accept as + the local host name. Place any domains or hosts that + sendmail is to be receiving mail for. + For example, if this mail server was to accept mail for the + domain example.com and the host + mail.example.com, its + local-host-names might look something like + this: + + example.com +mail.example.com + + When this file is updated, &man.sendmail.8; needs to be + restarted for it to read the changes. + + + + <filename>/etc/mail/mailer.conf</filename> + + The mailer.conf configuration file + holds a table containing the real mailer that is used for the + given action. Very old software programs would hard-code in the + name and path to the mailer, + /usr/sbin/sendmail, which meant they where + incompatable with other mailers such as postfix. Today, + /usr/sbin/sendmail is a wrapper that looks + at /etc/mail/mailer.conf and executes the + correct binary. When another mail transfer agent is installed + on the system, mailer.conf should be + updated to reflect the correct programs to execute. + + + + <filename>/etc/mail/sendmail.cf</filename> + + sendmail's master configuration + file, sendmail.cf controls the overall + behavior of sendmail. Everything + from rewriting e-mail addresses to printing reject messages for + remote mail servers. Naturally, with such a diverse role, this + configuration file is quite complex and its details are a bit + out of the scope of this chapter. Fortunately, this file rarely + needs to be changed for standard mail servers. + + The master sendmail configuration + file can be built from &man.m4.1; macros that define features + and behavior of sendmail. Please see + /usr/src/contrib/sendmail/cf/README for + some of the details. + + When changes to this file are made, + sendmail needs to be restarted for + the changes to take effect. + + + + <filename>/etc/mail/virtusertable</filename> + + The virtualusertable maps mail for virtual domains and + mailboxes to real mailboxes. These mail boxes can be local, + remote, point to an alias defined in + /etc/mail/aliases or to a file. + + + Example Virtual Domain Mail Map + + root@example.com root +postmaster@example.com postmaster@noc.example.net +@example.com joe + + + In the above example, we have a mapping for a domain + example.com. This file is processed in a + first match order down the file. The first item, maps + root@example.com to the local mailbox root. The next entry maps + postmaster@example.com to the mailbox postmaster on the host + noc.example.net. Finally, if nothing from example.com has + matched so far, it will match the last mapping, which matches + every other mail message addressed to someone at example.com. + This will be mapped to the local mail box joe. + + + Troubleshooting email troubleshooting - Here are some frequently asked questions and answers. These - have been migrated from the FAQ. - Why do I have to use the FQDN for hosts on my site? You will probably find that the host is actually in a different domain; for example, if you are in foo.bar.edu and you wish to reach a host called mumble in the bar.edu domain, you will have to refer to it by the fully-qualified domain name, mumble.bar.edu, instead of just mumble. BIND Traditionally, this was allowed by BSD BIND resolvers. However the current version of BIND that ships with FreeBSD no longer provides default abbreviations for non-fully qualified domain names other than the domain you are in. So an unqualified host mumble must either be found as mumble.foo.bar.edu, or it will be searched for in the root domain. This is different from the previous behavior, where the search continued across mumble.bar.edu, and mumble.edu. Have a look at RFC 1535 for why this was considered bad practice, or even a security hole. As a good workaround, you can place the line: search foo.bar.edu bar.edu instead of the previous: domain foo.bar.edu into your /etc/resolv.conf. However, make sure that the search order does not go beyond the boundary between local and public administration, as RFC 1535 calls it. - Sendmail says mail loops back to - myself + sendmail says mail + loops back to myself - This is answered in the sendmail FAQ as follows: + This is answered in the + sendmail FAQ as follows: * I am getting Local configuration error messages, such as: 553 relay.domain.net config error: mail loops back to myself 554 <user@domain.net>... Local configuration error How can I solve this problem? You have asked mail to the domain (e.g., domain.net) to be forwarded to a specific host (in this case, relay.domain.net) by using an MX record, but the relay machine does not recognize itself as domain.net. Add domain.net to /etc/sendmail.cw (if you are using FEATURE(use_cw_file)) or add Cw domain.net to /etc/sendmail.cf. - The sendmail FAQ is in + The sendmail FAQ is in /usr/src/usr.sbin/sendmail and is recommended reading if you want to do any tweaking of your mail setup. + PPP - PPP How can I do email with a dial-up PPP host? You want to connect a FreeBSD box on a lan, to the Internet. The FreeBSD box will be a mail gateway for the lan. The PPP connection is non-dedicated. There are at least two ways to do this. UUCP The other is to use UUCP. The key is to get a Internet site to provide secondary MX service for your domain. For example: bigco.com. MX 10 bigco.com. MX 20 smalliap.com. Only one host should be specified as the final recipient (add Cw bigco.com in /etc/sendmail.cf on bigco.com). When the senders' sendmail is trying to deliver the mail it will try to connect to you over the modem link. It will most likely time out because you are not online. sendmail will automatically deliver it to the secondary MX site, i.e., your Internet provider. The secondary MX site will try every (sendmail_flags = -bd -q15m in /etc/rc.conf) 15 minutes to connect to your host to deliver the mail to the primary MX site. You might want to use something like this as a login script. #!/bin/sh # Put me in /usr/local/bin/pppbigco ( sleep 60 ; /usr/sbin/sendmail -q ) & /usr/sbin/ppp -direct pppbigco If you are going to create a separate login script for a user you could use sendmail -qRbigco.com instead in the script above. This will force all mail in your queue for bigco.com to be processed immediately. A further refinement of the situation is as follows. Message stolen from the &a.isp;. > we provide the secondary MX for a customer. The customer connects to > our services several times a day automatically to get the mails to > his primary MX (We do not call his site when a mail for his domains > arrived). Our sendmail sends the mailqueue every 30 minutes. At the > moment he has to stay 30 minutes online to be sure that all mail is > gone to the primary MX. > > Is there a command that would initiate sendmail to send all the mails > now? The user has not root-privileges on our machine of course. In the privacy flags section of sendmail.cf, there is a definition Opgoaway,restrictqrun Remove restrictqrun to allow non-root users to start the queue processing. You might also like to rearrange the MXs. We are the 1st MX for our customers like this, and we have defined: # If we are the best MX for a host, try directly instead of generating # local config error. OwTrue That way a remote site will deliver straight to you, without trying the customer connection. You then send to your customer. Only works for hosts, so you need to get your customer to name their mail machine customer.com as well as hostname.customer.com in the DNS. Just put an A record in the DNS for customer.com. Advanced Topics The following section covers more involved topics such as mail configuration and setting up mail for your entire domain. Basic Configuration email configuration Out of the box, you should be able to send email to external hosts as long as you have set up /etc/resolv.conf or are running your own name server. If you would like to have mail for your host delivered to that specific host, there are two methods: Run your own name server and have your own domain. For example, FreeBSD.org Get mail delivered directly to your host. This is done by delivering mail directly to the current DNS name for your machine. For example, example.FreeBSD.org. SMTP Regardless of which of the above you choose, in order to have mail delivered directly to your host, you must have a permanent (static) IP address (no dynamic PPP dial-up). If you are behind a firewall, it must pass SMTP traffic on to you. If you want to receive mail at your host itself, you need to be sure of one of two things: MX record Make sure that the MX record in your DNS points to your host's IP address. Make sure there is no MX entry in your DNS for your host. Either of the above will allow you to receive mail directly at your host. Try this: &prompt.root; hostname example.FreeBSD.org &prompt.root; host example.FreeBSD.org example.FreeBSD.org has address 204.216.27.XX If that is what you see, mail directly to yourlogin@example.FreeBSD.org should work without problems. If instead you see something like this: &prompt.root; host example.FreeBSD.org example.FreeBSD.org has address 204.216.27.XX example.FreeBSD.org mail is handled (pri=10) by hub.FreeBSD.org All mail sent to your host (example.FreeBSD.org) will end up being collected on hub under the same username instead of being sent directly to your host. The above information is handled by your DNS server. The DNS record that carries mail routing information is the Mail eXchange entry. If no MX record exists, mail will be delivered directly to the host by way of its IP address. The MX entry for freefall.FreeBSD.org at one time looked like this: freefall MX 30 mail.crl.net freefall MX 40 agora.rdrop.com freefall MX 10 freefall.FreeBSD.org freefall MX 20 who.cdrom.com As you can see, freefall had many MX entries. The lowest MX number is the host that ends up receiving the mail in the end while the others will queue mail temporarily if freefall is busy or down. Alternate MX sites should have separate Internet connections from your own in order to be the most useful. Your ISP or other friendly site should have no problem providing this service for you. Mail for Your Domain In order to set up a mailhost (a.k.a., mail server) you need to have any mail sent to various workstations directed to it. Basically, you want to hijack any mail for your domain (in this case *.FreeBSD.org) and divert it to your mail server so your users can check their mail via POP or directly on the server. DNS To make life easiest, a user account with the same username should exist on both machines. Use adduser to do this. The mailhost you will be using must be the designated mail exchange for each workstation on the network. This is done in your DNS configuration like so: example.FreeBSD.org A 204.216.27.XX ; Workstation MX 10 hub.FreeBSD.org ; Mailhost This will redirect mail for the workstation to the mailhost no matter where the A record points. The mail is sent to the MX host. You cannot do this yourself unless you are running a DNS server. If you are not, or cannot, run your own DNS server, talk to your ISP or whoever does your DNS for you. If you're doing virtual email hosting, the following information will come in handy. For the sake of an example, we will assume you have a customer with their own domain, in this case customer1.org and you want all the mail for customer1.org sent to your mailhost, which is named mail.myhost.com. The entry in your DNS should look like this: customer1.org MX 10 mail.myhost.com You do not need an A record if you only want to handle email for the domain. Be aware that this means pinging customer1.org will not work unless an A record exists for it. The last thing that you must do is tell sendmail on your mailhost what domains and/or hostnames it should be accepting mail for. There are a few different ways this can be done. Either of the following will work: Add the hosts to your /etc/sendmail.cw file if you are using the FEATURE(use_cw_file). If you are using sendmail 8.10 or higher, the file is /etc/mail/local-host-names. Add a Cwyour.host.com line to your /etc/sendmail.cf or /etc/mail/sendmail.cf if you are using sendmail 8.10 or higher.