Mail Service - Server

Table of Contents:

• Introduction
• Process Queued Mail and Recieve incoming Mail
  • the inetd (alternative)
• Processing pop requests
  • using the IMAP Toolkit (alternative)
  • testing the IMAP Server
• Sendmail Configuration
  • who am i?
  • slow startup - gethostbyname() blocks
  • Relaying Access Denied
• Simple Diagnostics
  • What's in the QUEUE
  • Debug and Verbose Mode
  • Looking up MX Records
• Author and Copyright

Introduction

E-Mail services on the Internet exchange messages through a clients/servers mechanism where the client sends and retrieves mail from servers who store these messages for future forwarding (store and forward.) Three components of e-mail (as noted above) is the service for (a) clients to recieve their mail (b) servers to recieve mail from clients 'store', and (c) servers to 'forward' stored mail.

OpenBSD 2.6 && 2.7's default configuration for Sendmail is to process the mail queue 'forward stored mail' every 30 minutes "–q30m"

The above does not service client requests for mail, nor provide services for clients to send mail. The two internet services for client mail services are pop and smtp.

In this brief we will configure sendmail to process smtp requests. We will also install a daemon to process pop requests.

1. Setup services to process the SMTP as well as forwarding Mail Queues
2. Setup services for Processing POP

Process Queued Mail and Recieve incoming Mail

sendmail is installed as part of the base installation of OpenBSD 2.6 and 2.7. To have sendmail service smtp queries, we make changes to the /etc/rc.conf file.

File: /etc/rc.conf

change the line that reads

to be

The line specifies switches (command line options) that /etc/rc will pass sto sendmail during system startup. –bd tells sendmail to run as a daemon, running in the background, listening for and handling incoming SMTP connections. As a daemon, sendmail does a listen(2) on TCP port 25 for incoming SMTP messages. When another site connects to the listening daemon, the daemon performs a fork(2) and the child handles receipt of the incoming mail message. This is the preferred method for high use (smtp) servers.

The /etc/rc file checks for the value of the above 'options' and if options exist the /etc/rc will execute sendmail with the given options.

Further Documentation ? The Sendmail Operations Manual has a number of suggested recommendations, scripts clearly described for starting sendmail as an smtp service.

In a LAN only mail setup the queuing may not be necessary. The Sendmail bat book suggests 1h is a good setting for most sites, and for sites with few users –q15m may be appropriate to ensure immediate delivery of mail.

Starting sendmail - the inetd alternative

An alternative method for starting sendmail to process smtp requests is to use the inetd super server to launch sendmail on an as need basis.

Add a line (or modify an existing line) so that smtp requests causes an action by inetd

File: /etc/inetd.conf

The line tells inetd to launch sendmail on smtp requests. Verify that sendmail exists in the /usr/sbin folder. The “-bs” command tells sendmail to (a) be launched in “SMTP on standard input” (b) collect SMTP message over its standard input/output (c) deliver the message, and exit

Note that the above command does not specify when to process queued messages.

Force inetd to reload and read the new configuration by using the below command.

 # kill –HUP `cat /var/run/inetd.pid`

Note (alternative SMTP processor): OpenBSD 2.7 (2.6?) ships with the Obtuse Systems SMTPD message storing daemon (/usr/libexec/smtpd) and the Obtuse Systems SMTPFWDD message forwarding daemon (/usr/libexec/smtpfwdd). I haven't used it but it is documented in the man pages and http://www.obtuse.com/smtpd.html

Processing pop requests

Package: popa3d-0.3.tgz            (OpenBSD 2.6 or popa3d-0.4.tgz in OpenBSD 2.7)

source-file: cucipop-1.31.tar.gz    (available from the distfiles directory)

The simplest, fastest way to install the pop daemon is to install the popa3d-0.4.tgz package using pkg_add

# pkg_add /[path-to-package]/popa3d-0.4.tgz

pkg_add extracts the files and documentation from the popa3d package and specifically places the binary popa3d into the /usr/local/libexec directory. Verify the location of popa3d file.

Now we need to configure the super server inetd to route pop requests to be handled by our installed pop daemon. To do this we make the following changes.

File: /etc/services - Make sure there exists a line specifying port address 110 as a pop3 service

File: /etc/inetd.conf - Make sure you have a line specifying the pop services (pop3) and the responsibility for handling it is popa3d as shown in this example.

After making the changes, force inetd to re-read its configuration file by sending it the hang up signal.

# kill –HUP `cat /var/run/inetd.pid`

We now have a functioning smtp server (sendmail) and a functioning pop server (popa3d) Mail should be recieved and delivered on your mail-server.

pops and handling IMAP requests (alternative)

source-file: imap-4.7c2.tar.Z (available from the distfiles directory)

The UW IMAP Toolkit provides an IMAP server, necessary for advanced mailing options required by Web Based Mail services such as IMP and TWIG. The following is the process for installing and configuring an IMAP server:

(1) extract the source code,
(2) compile/make the binaries and
(3) copy the binaries to where other OpenBSD system tools expect the files.
(4) edit configuration files
(5) restart the inetd super-server

(1) Extract the source code, untar the distribution

# cd /usr/src
# tar -zxf /[path-to-tar-source]/imap-4.7c2.tar.Z
# cd imap-4.7c2

(2) Make/Compile the binaries.
We use "bso" to specify building for OpenBSD and the make process creates sub-directories c-client, ipopd and imapd where it makes the binaries to be used.
(3) After building we need to move the daemon files where we want to set up processing, I have chosen /usr/local/libexec because that's where the package system put the popa3d daemon so I hope I'm following some sort of standard with the file placement.

# make bso
# mv ipopd/ipop2d /usr/local/libexec
# mv ipopd/ipop3d /usr/local/libexec
# mv imapd/imapd /usr/local/libexec

[ref: IMP FAQ]

Optional: The next part is not necessary for mail delivery, but for compiling programs that need c-client (IMAP) support. The same results should be achievable by installing the c-client packages and copying only the *.h files described below.

Compiling IMAP support into programs will require the c-client header files in a 'standard' location and c-client library files. An example when these files are needed is if you compile php with IMAP support.

Optional: Documentation for IMAP is included with the source distribution and since I regularly clean out my /usr/src directories it would be good to manually copy the documentation to another location:

(4) Update the files /etc/services and /etc/inetd.conf where necessary (the files should be something similar to the following files.)

Review the file: /etc/services which should already have lines like the following:

Edit the file: /etc/inetd.conf and include lines like the following

(5) restart the inetd daemon

It is very important to restart inetd, otherwise inetd will not recognise the changes you placed into the /etc/inetd.conf file. There have been more than a few cases of people going through the hardwork configuring machines and then spending hours/days because trying to figure out why their system doesn't work, only to find out they left out this final stage.

Restart the inetd daemon.

Further Information:

The imap revision I use in this example was pulled down from the imap web-site (http://www.washington.edu/imap/) An earlier revision of the same release was available on the OpenBSD distfile mirrors, and the current release may be there now.

For some reason the php compilation fails without the 'ln -s /usr/local/lib/c-client.a usr/local/lib/libc-client.a' The actual file was not found on my hard disk and the closest file /usr/local/lib/libc-client4.a seems to be the same file ? If the above link is not performed than the php3-3.0.16 fails during compilation complaining about problems with the non-existent libc-client.a library.

If someone can give me simplified instructions on how to get IMAP working with a better IMAP server, I'll replace these instructions. After 3 years of these notes I still haven't had a cause to change my IMAP server, and thus have not ventured further. (Maybe this year.)

Testing the IMAP Server

How do I test an imap server?

[ref: How I test an imap server ]

The "abc1" etc at the begining of each command is just a tag you make up. Supposedly it should be unique for each line; I've found you can actually use the same tag over and over again.

Sendmail Configuration

The following are tweaks to the configuration files to get the system working smoothly on my configuration and may be helpful.

Who Am I ?

Sometimes things may not be happening because you just can't tell who you are (as the mail server.) To find out who sendmail things it is serving as, use the following commands.

The screen displays a number of useful information that may assist you in reviewing your assumptions about what settings have been given to sendmail.

slow start-up gethostbyname() blocks

When Sendmail starts it will try to determine the name of the server by using the gethostname and getbyhostname system call. You may also need to edit the /etc/hosts file for the reason specified below from the IMAP Toolkit FAQ

From the IMAP Toolkit FAQ

If your system pauses for a length of time when sendmail is started, the above situation may be the solution for your problem.

Make sure we have a fully qualified domain associated with each ip address used by the server. With two network cards, OpenBSD install will only specify the domain name for one of the network ip addresses. [Discovered the same problem with Linux Mandrake 7.1 install]

File: /etc/hosts

Relaying access denied

[Ref OpenBSD FAQ - 10.0 System Management -> 10.4 ... Relay Access Denied ...]

I want the server to service all smtp messages sent from users in my private-ip network, regardless of where on the network they are sending it from. To do this, we create the file /etc/mail/relay-domains and include a list of the host domains we will service. For example, if the server domain is mydomain.com then including mydomain.com in the /etc/mail/relay-hosts file lets me smtp messages from a remote client, so long as I specify my user information is @mydomain.com

Create or Edit: /etc/mail/relay-domains

mydomain.com

This, of course, is a serious security hole. Another approach is to allow by IP address (ie. local lan only) and use your firewall rules to block access by people saying their using your IP addresses coming in on your external network cards. But that's another story.

What we are doing above assumes the standard /etc/mail/sendmail.cf supplied with the OpenBSD 2.7 install. To verify the name of the file where we can place relay-domains use:

# cat /etc/mail/sendmail.cf | grep relay-domains

and the output would be something like this (if the the sendmail.cf supports relaying.)

FR-o /etc/mail/relay-domains

If you do not get something similar to the above, then you will have to create another sendmail.cf (cf. /usr/share/sendmail) Sendmail 8.9 changes the previous behaviour of Sendmail, where it now defaults to not forwarding e-mail to combat bulk-mailers/spammers. So, the sendmail.cf needs to include some support for relaying mail from other domains. Look at using

define(confCR_FILE,`/etc/mail/relay-domains')

General format for the /etc/mail/relay-domains file is:

Simple Diagnostics

Although sendmail is hard to grasp, there is an abundance of documentation on how to use, configure, and validate your sendmail configuration. This abundant information is available online and in print. The following tidbits are some of the commands I've used to check my sendmail configurations, they are in no special order and in many cases not cleverly written. For a list of reference resoureces visit the Sendmail site http//www.sendmail.org

What's in the Queue

To get a listing of mail stuck in the queue (not yet delivered and for what reason) then you can use the "-bp" option of sendmail. For example:

Debugging & Verbose Mode

-v (verbose) -d (debug) are two modes which print extra diagnostic information on the screen while processing.

sendmail -v user-id < info-to-send

The -v (verbose) option will display sendmail's activities in trying to send mail to user-id. I find this especially useful when trying to understand why sendmail fails trying to send to an external host. You can use a user-id on another machine to watch what sendmail's doing in trying to send your mail to that external host. For example:

sendmail -v user-id@remotehost.com < info-to-send

The above will display the sendmail session trying to connect to the SMTP port at remotehost.com. With the details of the connection you can see any rejection messages from the external host.

sendmail -d## user-id < info-to-send

The -d (debug) option (as it should) can generate a lot of information and it is up to you to select the level of information that is useful for isolating the cause of your problem. Further documentation should be available at http://www.sendmail.org otherwise I have seen the use of -d40 (limit output to information about the queue) -d0 (produce general debugging information, as shown in earlier example above.)

To get a comprehensive listing from sendmail of the current settings, use the -d option without qualifiers.

# sendmail -d < /dev/null

The screen output will display the compiled in options and some of the settings configured for sendmail. This is not a comprehensive list of settings.

Looking Up MX records

[ref: dig(1)]

sendmail prioritises mail using the MX records given by your DNS server. It may be useful sometimes to verify your assumptions of what the MX records are saying by interrogating the MX records with dig, and to follow a mail message using sendmail -v.

Dial-Up Mail Serving?

A few of the places we're working in do not have a live Internet connection, or prefers to process the world mail queue on a scheduled basis. On a dial-up class machine, we do not want the mail server attempting to send mail on every message and the below is one configuration that may be useful.

Essentially, we want the mail server to deliver local mail immediately, but hold all external mail until we process the queue. The concept is to define mail as expensive. For more details on implementation, consult the HOWTO Sendmail and dial-up modem internet by Wouter Hanegraaff

define(SMTP_MAILER_FLAGS, e)
define(`confTO_QUEUEWARN', `16h')
define(`SMART_HOST', `myISP')
MAILER(local)dnl
MAILER(smtp)dnl

I think from the above, smtp of local mail will get sent straight away. The
queue will only need to be processed when external mail needs to be
delivered (ie. when online)

From the docs:

Mailer Flag
e This mailer is expensive to connect to, so try to avoid connecting normally; any necessary connection will occur during a queue run.

Options:
There are a number of global options that can be set from a configuration file. Options are represented by full words; some are also representable as single characters for back compatibility.

The syntax of this line is:
O option=value

This sets option option to be value. Note that there must be a space between
the letter 'O' and the name of the option. An older version is:
Oo value

where the option o is a single character. Depending on the option, value may be a string, an integer, a boolean (with legal values "t", "T", "f", or "F"; the default is TRUE), or a time interval.

The options supported (with the old, one character names in brackets) are:

HoldExpensive [c] If an outgoing mailer is marked as being expensive, don't connect immediately. This requires that queueing be compiled in, since it will depend on a queue run process to actually send the mail.

Other Security Items

ESMTP

Authenticated Mail Relay.

Author and Copyright

Copyright (c) 2000/1/2 Samiuela LV Taufa. All Rights Reserved.

I reserve the right to be totally incorrect even at the best advice of betters. In other words, I'm probably wrong in enough places for you to call me an idiot, but don't 'cause you'll hurt my sensibilities, just tell me where I went wrong and I'll try again.

You are permitted and encouraged to use this guide for fun or for profit as you see fit. If you republish this work in what-ever form, it would be nice (though not enforceable) to be credited.

Copyright  © 2000/1/2 NoMoa.COM All rights reserved.