Chapter 15 LMTP Delivery

The Sun Java System Messaging Server MTA can use LMTP (Local Mail Transfer Protocol, defined in RFC 2033) for delivery to the message store in situations where a multi-tier messaging server deployment is used. In these scenarios, where you are using inbound relays and back end message stores, the relays become responsible for address expansion and delivery methods such as autoreply and forwarding and also for mailing list expansion. Delivery to the back end stores historically has been over SMTP which requires the back end system to look up the recipient addresses in the LDAP directory again, thereby engaging the full machinery of the MTA. For speed and efficiency, the MTA can use LMTP rather than SMTP to deliver messages to the back end store. The Sun Java System Messaging Server’s LMTP server is not intended as a general purpose LMTP server, but rather as a private protocol between the relays and the back end message stores. For simplicity of discussion, examples involving two-tier deployments are used.


Note	By design, LMTP is intended for use in multi-tier deployments. It is not possible to use LMTP with single-system deployments. Also, the Messaging Server’s LMTP service as implemented is not designed to work with other LMTP servers or other LMTP clients.

LMTP Delivery Features

The MTA’s LMTP server is more efficient for delivering to the back end message store because it:

Reduces the load on the back end stores.

Reduces the load on the LDAP servers.

Reduces the number of message queues.

Messaging Processing in a Two-Tier Deployment Without LMTP

Figure 15-1 presents in pictorial form the following discussion of message processing in a two-tier deployment scenario without LMTP.

Without LMTP, in a two level deployment with relays in front of the store systems, the processing of an inbound message begins with a connection on the SMTP port picked up by the dispatcher on the relay machine and handed off to a tcp_smtp_server process. This process does a number of things with the inbound message including:

Looking up the user in the directory

Determining if the user is within a domain hosted by this email deployment

Determining if the user is a valid user in the domain

Rewriting the envelope address as @mailhost:user@domain

Enqueuing the message for delivery to the mailhost

The smtp_client process then picks up the mail message from the queue and sends it to the mailhost. On the mailhost, some very similar processing takes place. A connection on the SMTP port is picked up by the dispatcher and handed off to a tcp_smtp_server process. This process does a number of things to the message, including:

Looking up the user in the directory

Determining if the user is within a domain hosted by this email deployment

Determining if the user is a valid user in the domain

Rewriting the envelope address to direct the message to the ims_ms channel

Enqueuing the message for delivery to the store

Then the ims_ms process picks up the mail message and attempts to deliver it to the store. In this scenario, the enqueuing processing is performed twice, and the MTAs each perform an LDAP lookup.

Messaging Processing in a Two-Tier Deployment With LMTP

Figure 15-2 presents in pictorial form the following discussion of message processing in a two-tier deployment scenario with LMTP.

With LMTP in place, a connection on the SMTP port of the relay machine is picked up by the dispatcher and handed off to a tcp_smtp_server process. This process does a number of things with the inbound message including:

Looking up the user in the directory

Determining if the user is within a domain hosted by this email deployment

Determining if the user is a valid user in the domain

Determining which back end message store machine hosts the mailbox for the user

Rewriting the address as @mailhost:uid@domain.LMTP or @mailhost:uid@domain.LMTPNATIVE

Enqueuing the message for delivery to the mailhost

Addresses of the format user@domain.LMTP and user@domain.LMTPNATIVE are routed to the message store system via a tcp_lmtp channel or a tcp_lmtpnative channel respectively. These channels communicate with the back end message store using LMTP instead of SMTP. On the store machine, a connection to the LMTP port is received by the dispatcher and handed off to the lmtp_server process. The LMTP server then inserts the message into the user's mailbox or into the UNIX native mailbox. If message delivery is successful, the message is dequeued on the relay machine. If unsuccessful, the message remains on the relay machine. Note that the LMTP process on the message store does not engage any MTA machinery for processing addresses or messages.

LMTP Overview

For the most part, the MTA itself can be basically absent from the back end server. The only necessary MTA components are:

The dispatcher

libimta

The LMTP server

The imta.cnf file

The mappings file

The imta.tailor file

While the dispatcher requires MTA configuration files, these files can be very short. The dispatcher must run on the back end server so that it can start the LMTP servers which run under it. Because the dispatcher and the LMTP server use various functions of libimta, this needs to be present on the back end server as well.

The LMTP server does not perform any of the usual MTA enqueuing or dequeuing functions, header processing, or address translations. The relay system performs all the manipulation of the content of the messages and addresses which then presents to the LMTP server the message in exactly the form to be delivered to the message store and with the delivery address already in the form required by the store. Additional recipient information that is usually available as a message is delivered to the store, such as the user’s quota, is presented along with the recipient address as LMTP parameters. Should a delivery attempt fail, the message is left enqueued in the LMTP queue on the relay system.

Configuring LMTP Delivery

Configuring the LMTP delivery mechanism requires configuration on both the relay machines and on the back end stores. On the relays, the DELIVERY_OPTIONS MTA option (in option.dat) has to be changed so that messages being delivered to the stores are passed to the LMTP channel. The back end store must be configured with the dispatcher, but does not need the job controller. The dispatcher must be configured to run the LMTP server.

In a typical multi-tier deployment, users are provisioned on different backend message store machines. One or more of these backend machines may not have LMTP turned on and therefore the front-end relays need to be aware of which store machines are LMTP aware. This is achieved by using the General Database facility to explicitly name those message stores which are configured to accept LMTP delivery.

To Configure the Inbound MTA Relays with LMTP

Activate text databases by adding the following line to option.dat:

USE_TEXT_DATABASES=1

In this step, the use of a flat text file for the General Database is enabled in the MTA. Note that if you already use the general database, you may want to skip this step.

Create or modify the General Database text file.

# cd /opt/SUNWmsgsr/config/
# vi general.txt

LMTP_CS|msg-store.siroe.com lmtpcs-daemon
LMTP_CS|name-1-lmtp-store.siroe.com lmtpcs-daemon
LMTP_CS|name-2-lmtp-store.siroe.com lmtpcs-daemon
..
..
LMTP_CN|Zmar.Talek@siroe.com lmtpcn-daemon
..
LMTP_CN|Fred.Bloggs@siroe.com lmtpcn-daemon

# chown mailsrv general.txt

There two types of entries, one for handling user specific deliveries to the lmtpnative channel and one for handling store wide settings for delivery via the tcp_lmtpcs channel.

Create or modify the DELIVERY_OPTIONS variable in the options.dat file.

The value of DELIVERY_OPTIONS must be changed. The current default for delivery options is:

DELIVERY_OPTIONS=\
     *mailbox=$M%$\$2I$_+$2S@ims-ms-daemon,\
     &members=*,\
     *native=$M@native-daemon,\
     *unix=$M@native-daemon,\
     /hold=$L%$D@hold-daemon,\
     &file=+$F@native-daemon,\
     &@members_offline=*,\
     program=$M%$P@pipe-daemon,\
     #forward=**,\
     *^!autoreply=$M+$D@bitbucket

Change this to:

DELIVERY_OPTIONS=\
    #*mailbox=@$X:$M$_+$2S%$\$2I@ims-ms-daemon,\
    #&members=*,\
    #*native=@$X:$M,\
    #*unix=@$X:$M,\
    #/hold=$L%$D@hold,\
    #*file=@$X:+$F,\
    #&@members_offline=*,\
    #program=$M%$P@pipe-daemon,\
    #forward=**,\
    #*^!autoreply=$M+$D@bitbucket

Note the change in the pattern for the mailbox delivery option and that the autoreply delivery option is now preceded by the character # to force action on the relay machine. The $X substitution inserts the value of the mailhost attribute for the user. This generates a source routed address.

Also note that for native, UNIX, file and program delivery methods to be useful, the MTA must be running on the target machine.

Add an LMTP rewrite rule to the imta.cnf file:

# cd /opt/SUNWmsgsr/config/
# cp imta.cnf imta.cnf.orig
# vi imta.cnf

!
! pipe
.pipe-daemon $U%$H.pipe-daemon@pipe-daemon
!
! tcp_local
! Rules for top level internet domains
<IMTA_TABLE:internet.rules
!
! Do mapping lookup for internal IP addresses
[] $E$R${INTERNAL_IP,$L}$U%[$L]@tcp_intranet-daemon
!
! Do general.txt lookup for lmtp hosts
.domain-name.com $S$U%$H$D@$(LMTP_CN|$U@$H$D)
.domain-name.com $S$U%$H$D@$(LMTP_CS|$H$D)
!
! tcp_intranet
! Do mapping lookup for internal IP addresses
[] $E$R${INTERNAL_IP,$L}$U%[$L]@tcp_intranet-daemon
.domain-name.com $U%$H.domain-name.com@tcp_intranet-daemon

In this step, a pair of rewrite rules do a tagged probe of the General Database to see if the source route portion of the address matches any entries for doing LMTP delivery. In the general.txt file, which was created in Step 2, there are tagged entries to designate delivery to the backend message store via the appropriate channel. Here, the $S in the rewrite rule means that it will only apply when the address contains a source route. If there is a match to an entry in the General Database, the rewrite rule succeeds and the message is sent to the source route backend host via the tcp_lmtpX channel which does delivery via LMTP.

If a match is not found, the rewrite process will continue until a match is found in some other rewrite rule. In most cases, if a match is not found via a probe of the General Database, then message is routed via the tcp_intranet channel which does delivery via SMTP.

Add new channel blocks to imta.cnf

You must also include channel definitions for the lmtp and lmtpn channels in the channel definition section of the imta.cnf file. For example:

! tcp_lmtpcs (LMTP client - store)
tcp_lmtpcs defragment lmtp port 225 nomx single_sys subdirs 20 maxjobs 7 pool SMTP_POOL dequeue_removeroute
lmtpcs-daemon
!
! tcp_lmtpcn (LMTP client - native)
tcp_lmtpcn defragment lmtp port 226 nomx single_sys subdirs 20 maxjobs 7 pool SMTP_POOL dequeue_removeroute
!lmtpcn-daemon

Commit your configuration changes.

# cd /opt/SUNWmsgsr/bin
# ./imsimta refresh

Compiled configuration done

Killing Dispatcher : 23021

Dispatcher startup requested

Job Controller shutdown requested

Job Controller startup requested



Note	Be sure to use the lmtp channel keyword on LMTP channels. Do not use both smtp and lmtp channel keywords on LMTP channels. Note also that by default, the LMTP channel definitions are commented out. You must uncomment them if you want LMTP to work.

If you have an organization with Sun Java System Messaging Server users as well and non-Sun Java System Messaging Server users, you need to be able to indicate which users are on non-Sun Java System Messaging Server machines. Those user’s delivery option cannot be set to mailbox. Instead, their delivery option must be set to forward. That forwarding address should be in the source routed form and can be any of (but not limited to) the following examples:

Configuring the Back End Stores with LMTP and No MTA

The back end stores need no MTA if they are receiving messages over LMTP. This means that they have no job controller, and none of the address rewriting machinery associated with the MTA. They do however still require a dispatcher and a simple MTA configuration. In particular they need a dispatcher.cnf file and a mappings file which comprise the only significant part of the MTA configuration.

Note that by default, the LMTP services in the dispatcher.cnf file are commented out. You must uncomment them to get LMTP to work.

The normal dispatcher options of MAX_CONNS, MAX_PROCS, MAX_LIFE_CONNS, and MAX_LIFE_TIME can also be set, but need to be set appropriately for your hardware.

The PORT_ACCESS mapping is important. The LMTP implementation for the back end servers is intended as a private protocol between Sun Java System Messaging Server relays and back end stores. You must use the PORT_ACCESS mapping to make sure that only such relays can connect to these services. Your mapping file should look like this:

You should replace the sample IP addresses specified in the PORT_ACCESS mapping table here with the IP addresses of your relays on the network that connect to the back end stores.

There has to be an imta.cnf file, but it is there merely to make the configuration complete. A minimal imta.cnf file consists of the following channel definitions:

Note that by default, the LMTP channel definitions are commented out. You must uncomment them if you want LMTP to work.

Configuring Relays for Sending Messages Via LMTP to Back End Systems with Message Stores and Full MTAs

There are situations where you might want the back end stores to have the full capabilities of the MTA but still to have the load savings of using LMTP. For example, you might want program delivery on the back end store. In this case the relays should be configured as described above in To Configure the Inbound MTA Relays with LMTP.

Configuring LMTP on Back End Message Store Systems Having Full MTAs

The only changes from the configuration of a back end store messaging system to one with LMTP direct delivery to the store are that the following lines need to be added to the end of the dispatcher.cnf file:

Note that by default, the LMTP services in the dispatcher.cnf file are commented out. You must uncomment them to get LMTP to work. Also, the LMTP port numbers are just examples, and can be anything you choose.

This is the same as the whole dispatcher.cnf file described above for when the back end store is configured only for LMTP. The mappings file also requires the PORT_ACCESS mappings as described for LMTP only back end stores.

LMTP Protocol as Implemented

This section provides a sample LMTP dialogue with an explanation of what is seen in that dialogue. The LMTP client on the relay uses standard LMTP protocol to talk to the LMTP server on the back end store. However the protocol is used in specific ways. For example:

No checks or conversions are made on the originator address. The size= parameter gives a size in bytes for the message that is to be delivered. This is the size of the message exactly as it appears in the protocol. It is not necessarily the exact size of the message, but the actual message size will not exceed this size. The LMTP server allocates a memory buffer of this size to receive the message.

No checks are made on the recipient addresses at the time they are received, but a list of recipients is built for later use. Note that the @domain part of the address is omitted for uids in the primary domain, and that the +folder part is optional. This is the same address format used by the message store channel in the MTA.

The xquota= parameter gives the user’s message quotas which consist of the maximum total size and the maximum number of messages. The MTA provides this information which it retrieves while performing an LDAP lookup on the user to do the address translation. This information is used to keep the quota information in the message store synchronized with the directory. Getting the quota information does not result in an additional performance hit.

The xdflg= parameter specifies a number which is interpreted as a bit field. These bits control how the message is delivered. For example, the bit whose value is 2, if set, guarantees delivery of the message even if the user is over quota. (Note that xdflg is an internal parameter and the bits in it are subject to change or addition without notice. We do not support other clients using this extension with our server, nor do we support using our client with some other server and this parameter.)

The LMTP client then sends the entire message, dot-stuffed, just as SMTP does. The message finishes with a dot (.) alone on a line. If the message size is exceeded the LMTP server sends:

Assuming that the message is received correctly, the LMTP server then sends back to the LMTP client the status for each recipient given in the RCPT TO: lines. For instance, if the message is delivered successfully, the response is:

The conversation can either repeat with another MAIL FROM: line or end with the following interaction:

Table 15-1 shows the possible status codes for each recipient. This three-column table shows the short code in the first column, its long-code equivalent in the second column and the status text in the third column. 2.x.x status codes are success codes, 4.x.x codes are retryable errors, 5.x.x codes are non retryable errors.

Table 15-1 LMTP Status Codes for Recipients
Short Code	Long Code	Status Text
250	2.5.0	OK
420	4.2.0	Mailbox Locked
422	4.2.2	Quota Exceeded
420	4.2.0	Mailbox Bad Formats
420	4.2.0	Mailbox not supported
430	4.3.0	IMAP IOERROR
522	5.2.2	Persistent Quota Exceeded
523	5.2.3	Message too large
511	5.1.1	mailbox nonexistent
560	5.6.0	message contains null
560	5.6.0	message contains nl
560	5.6.0	message has bad header
560	5.6.0	message has no blank line

Otherwise, there are changes to the delivery options for mailbox, native (and, therefore, UNIX), and file. The object of these rules is to generate addresses that will cause the messages to be sent through the appropriate LMTP channel to the back end servers. The addresses generated are source routed addresses of the form:

Previous Contents Index Next
Sun Java System Messaging Server 6 2005Q1 Administration Guide