Understood. I'llto go with the LMTP method using an already running
daemon. In order to configure this, do I have the entry in master.cf use
lmtp as the transport type, and have argv=localhost:someport, and use
virtual_transport (with the other virual_maps/domains etc) using the new
definition? Finding examples is not easy, unfortunately :)
In the meantime, I'll give this a go.
Thanks!
Wietse Venema wrote:
Matt Burgoon:
I'm running into some performance issues with the sheer volume of email
I'm dealing with that is destined to a perl script for final email
delivery. The start up cost of this particular perl script is not
insubstantial, and is slowly bringing this poor box to its knees. I've
done as much optimization as I can, and the only logical next step is to
turn it into a daemon, so I no longer have to worry about the initial
start up cost of this script.
SMTP and LMTP are the only supported interfaces for delivery from
postfix into resident programs. You could also use the Milter
interface for this, but that would be perverse.
I fully expect to have to implement that can actually speak LMTP or
something else postfix speaks, so I have no illusions that this is going
to be super easy.
SMTP/LMTP are really super easy, because SMTP-for-Perl etc.
implementations already exist.
If worse comes to worse, I can run this script as a daemon that accepts
unix socket connections, then have the local delivery agent replacement
just make a connection, spew the email over the connection and exit, but
You can't use Postfix's internal protocols. Programs that depends
on internal interfaces are not supported.
While great care is taken not to break compatibility of the external
interfaces, the internals do change without any announcement and
without any consideration for backwards compatibility.
Wietse