On Mon, Jul 01, 2019 at 03:19:37PM +0000, Patton, Matthew [Contractor] wrote:
> I need a way for Postfix to listen to SMTP (think smarthost) and then
> re-send all emails via HTTP POST operation. Is the correct way to tackle
> this (aside from telling them to go to hell) a transport definition using
> Pipe(8)? I've never done this before and it doesn't appear to be a very
> common scenario. Otherwise I could write a small Perl program that is
> launched via inetd, that would do the same even though it wouldn't be very
> efficient.
Two key reasons that SMTP servers have queues:
* Multi-recipient messages may require forwarding of a "split-envelope"
to multiple domains. This can't be done atomically, so the message
is queued and the separate parts are delivered asynchronously.
* Forwarding may be to remote systems that are not always up, but the
client may be ephemeral and unable to retry.
If in your case all message are always shunted to the same destination
one-in/one-out, and the destination is sufficiently available, or
the client is capable of retries, a non-queueing proxy may well be
a better choice than an MTA. It could even be more efficient (if
it avoids fork/exec of scripts that involve CPU-intensive parsing
the code each time).
The SMTP proxy can return 4XX if the HTTP POST fails. It can run
as a threaded or forking server. In Python or Perl, I'd go with a
forking server for simplicity. In Haskell, threading is very
light-weight and safe/correct concurrency is pain-free, so if you
need a lot more performance, Haskell (or Rust) would likely raise
your throughput ceiling by an order of magnitude.
--
Viktor.
