OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: Re: LMTP -- how to do alias expansion + LMTP delivery
From: Amos Gouaux (amos+lists.postfixutdallas.edu)
Date: Tue May 23 2000 - 11:56:10 CDT

>>>>> On 22 May 2000 21:55:04 -0700,
>>>>> Rupa Schomaker <rupa-list+postfixrupa.com> (rs) writes:

rs> The LMTP patches prior to official merging allows for two ways to do
rs> LMTP. One is via tcpip using a transport to set the next hop and the
rs> other is to directly give the command to execute in the master.cf.

rs> The adoption of the LMTP patches have preserved only the first
rs> method. On the surface this makes perfect sense, and was the final
rs> goal even for the original patches.

I've corresponded some with Walter Steiner about this very
issue. Currently, if you want to use LMTP delivery with alias
expansion on the same box _and_ send to multiple recipients at the
same time for single-store delivery, you'll have to do a little
work. Though, with a simple script this should be pretty easy to
resolve.

Actually, in truth, the local delivery mechanism in the old LMTP
hacks was "broken" as well since they didn't support multiple
recipients either. Since I do all LMTP to another host, I didn't
discover this until Mr. Steiner pointed it out. So in the end,
dropping that code not only makes for a drastically simpler, easier
to maintain service, but also little real functionality is lost.

Basically, you'd have a transport map entry like this:

lmtpdeliver.sample.org lmtp:[127.0.0.1]

Then use a virtual table to map those that should receive their mail
via the LMTP service:

user1sample.org user1lmtpdeliver.sample.org

The nice thing about this approach is that it would allow you to
scale to multiple LMTP servers pretty easily. The next step would
be to replace such virtual table entries with an LDAP query, which
happens to be next on my agenda.

In terms of the LMTP connection caching and multiple recipients,
I've also played with some of these settings:

# This is mainly set to increase the
# connection caching with the lmtp service.
max_use = 200

# Cyrus will hard link messages to multiple recipients
# on the same Cyrus partition.
lmtp_destination_recipient_limit = 1000

If I understand things correctly, I think it will be possible to
specify some of these using the `-o' flag in master.cf. If so,
perhaps the max_use setting could be applied to just the lmtp
service, which I suspect would be better.

Also in master.cf, I currently have:

lmtp unix - - n - 4 lmtp

I lowered the allowable number of lmtp clients to make greater use
of the connection caching. This is also nice in that if the SMTP
server gets hit with a bunch of mail all at once, the IMAP/POP
systems won't get overwhelmed. Naturally, you'll want to watch
delivery to make sure you don't choke off things tooo much.

Amos