Using Postfix sendmail without having Postfix daemon running all the time?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Using Postfix sendmail without having Postfix daemon running all the time?

Otto Kekäläinen
Hello!

Is it possible to send email using the Postfix provided
/usr/sbin/sendmail command on a system where Postfix is installed, but
not running permanently as a service?


Background:

I have a resource constrained system where I want to avoid running
excess processes, and it rarely sends email. When it sends, it just
relays to a proper Postfix host accessible on the local network. There
is no incoming nor local mail delivery needs on that system.

I have been using msmtp for this need, but its handling of multiple
recipients in the same mail is too simple and I'd rather use Postfix
that parses and validates recipients properly.

In my testing the command sendmail on a system where Postfix is
installed does accept the email but it puts it in a local queue
(verified by mailq) and then the queue just sits still and no mail is
delivered. Manually running postflush complains that Postfix is not
running. If I quickly cycle 'postfix start' and 'postfix stop' the
service starts and sends out the queue and everything works, but
ideally I'd like an invocation of /usr/sbin/sendmail to immediately
send off the email to the relay host and not depend on a permanently
running Postfix daemon. Is this possible?

I've tested the -G and -q options mentioned at
http://www.postfix.org/sendmail.1.html but they don't seem to do this
what I was looking for.
Reply | Threaded
Open this post in threaded view
|

Re: Using Postfix sendmail without having Postfix daemon running all the time?

Nicky Thomassen
YMMW, but I solved this using ssmtp to replace sendmail. According to Arch it
may be  poor choice, since it is not maintained

https://wiki.archlinux.org/index.php/SSMTP

Just my 2 cents



Thu, 6 Aug 2020 09:44:24 +0300 skrev Otto Kekäläinen <[hidden email]>:

> Hello!
>
> Is it possible to send email using the Postfix provided
> /usr/sbin/sendmail command on a system where Postfix is installed, but
> not running permanently as a service?
>
>
> Background:
>
> I have a resource constrained system where I want to avoid running
> excess processes, and it rarely sends email. When it sends, it just
> relays to a proper Postfix host accessible on the local network. There
> is no incoming nor local mail delivery needs on that system.
>
> I have been using msmtp for this need, but its handling of multiple
> recipients in the same mail is too simple and I'd rather use Postfix
> that parses and validates recipients properly.
>
> In my testing the command sendmail on a system where Postfix is
> installed does accept the email but it puts it in a local queue
> (verified by mailq) and then the queue just sits still and no mail is
> delivered. Manually running postflush complains that Postfix is not
> running. If I quickly cycle 'postfix start' and 'postfix stop' the
> service starts and sends out the queue and everything works, but
> ideally I'd like an invocation of /usr/sbin/sendmail to immediately
> send off the email to the relay host and not depend on a permanently
> running Postfix daemon. Is this possible?
>
> I've tested the -G and -q options mentioned at
> http://www.postfix.org/sendmail.1.html but they don't seem to do this
> what I was looking for.

Reply | Threaded
Open this post in threaded view
|

Re: Using Postfix sendmail without having Postfix daemon running all the time?

Ansgar Wiechers
In reply to this post by Otto Kekäläinen
On 2020-08-06 Otto Kekäläinen wrote:
> Is it possible to send email using the Postfix provided
> /usr/sbin/sendmail command on a system where Postfix is installed,
> but not running permanently as a service?

You could wrap the command in a script that starts and stops the Postfix
service when invoked.

    #!/bin/bash
    sudo service postfix start
    sendmail ...
    sudo service postfix stop

However, I wouldn't recommend doing that since you'd have to manage
concurrency, handle errors and other fun things.

Postfix isn't that heavy on system resources. Just configure it as a
null client [0] that sends to your upstream Postfix and leave it running
in the background.

Alternatively use something like mailx [1] to send directly through the
upstream server:

    echo "message" | mailx -S smtp=smtp://mail.example.com ...

[0]: http://www.postfix.org/STANDARD_CONFIGURATION_README.html#null_client
[1]: https://www.systutorials.com/sending-email-using-mailx-in-linux-through-internal-smtp/

Regards
Ansgar Wiechers
--
"Abstractions save us time working, but they don't save us time learning."
--Joel Spolsky
Reply | Threaded
Open this post in threaded view
|

Re: Using Postfix sendmail without having Postfix daemon running all the time?

Bastian Blank-3
In reply to this post by Otto Kekäläinen
On Thu, Aug 06, 2020 at 09:44:24AM +0300, Otto Kekäläinen wrote:
> Is it possible to send email using the Postfix provided
> /usr/sbin/sendmail command on a system where Postfix is installed, but
> not running permanently as a service?

Sure, the sendmail command will just deposit the mail into the maildrop
queue.

> I have a resource constrained system where I want to avoid running
> excess processes, and it rarely sends email. When it sends, it just
> relays to a proper Postfix host accessible on the local network. There
> is no incoming nor local mail delivery needs on that system.

What do you mean with "resource constrained"?  An idle postfix starts
master, qmgr and tlsproxy.  There are not much resources involved.

> I have been using msmtp for this need, but its handling of multiple
> recipients in the same mail is too simple and I'd rather use Postfix
> that parses and validates recipients properly.

Don't.  Use some specialized null mailer, I usually use "nullmailer".
It will send all e-mail to exactly one smart host.

>                                                              but
> ideally I'd like an invocation of /usr/sbin/sendmail to immediately
> send off the email to the relay host and not depend on a permanently
> running Postfix daemon. Is this possible?

No, it is not possible.  Postfix is no single service.

Bastian

--
Youth doesn't excuse everything.
                -- Dr. Janice Lester (in Kirk's body), "Turnabout Intruder",
                   stardate 5928.5.
Reply | Threaded
Open this post in threaded view
|

Re: Using Postfix sendmail without having Postfix daemon running all the time?

Viktor Dukhovni
In reply to this post by Otto Kekäläinen
On Thu, Aug 06, 2020 at 09:44:24AM +0300, Otto Kekäläinen wrote:

> Is it possible to send email using the Postfix provided
> /usr/sbin/sendmail command on a system where Postfix is installed, but
> not running permanently as a service?

Not the upstream Postfix version signed by Wietse.  Apple have
(had?) a modified Postfix Postfix version that does support idling
down when the mail queue is empty.

For that you need an "inotify" daemon that watches the queue directory,
waking up only as files are added or deleted.  It needs to be very
robust, never getting out of sync with the queue contents.  So long as
the maildrop, incoming, active or deferred queues are non-empty, Postfix
should be running.  Once all four are empty Postfix can be stopped, to
be restarted once a new file lands in the maildrop directory.

A doable, but perhaps non-trivial, programming project would be to start
with Apple's Postfix sources, and port that functionality to BSD and/or
Linux.

When there's no new mail, the cost of running Postfix is that the queue
manager and pickup "wake up" periodically, to scan the queue directory
for new messages.  This can prevent battery-powered devices from
entering an energy-saving sleep mode.

Otherwise, provided max_idle is less than the wakeup timer for "pickup",
the cost is modest. Postfix idles down to just 3 processes:

    /usr/local/libexec/postfix/master -w
    qmgr -l -t unix -u
    pickup -l -t unix -u

with pickup(8) waking up every 60 seconds by default (see master.cf(5))
and qmgr(8) waking up to scan the queue every 300 seconds.  You can
reduce the cost of qmgr scans by disabling hashing of the deferred
queue after stopping Postfix, and then restarting.

    hash_queue_names =

--
    Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: Using Postfix sendmail without having Postfix daemon running all the time?

Viktor Dukhovni
On Thu, Aug 06, 2020 at 02:38:21PM -0400, Viktor Dukhovni wrote:

> Otherwise, provided max_idle is less than the wakeup timer for "pickup",
> the cost is modest. Postfix idles down to just 3 processes:

Correction, typo, max_idle should be *greater* than the wakeup timer for
pickup.

--
    Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: Using Postfix sendmail without having Postfix daemon running all the time?

Bill Cole-3
In reply to this post by Viktor Dukhovni
On 6 Aug 2020, at 14:38, Viktor Dukhovni wrote:

> A doable, but perhaps non-trivial, programming project would be to
> start
> with Apple's Postfix sources, and port that functionality to BSD
> and/or
> Linux.

Not very doable, because the trigger was handled by launchd, Apple's
systemd-like facility. The timed death of the Postfix master process is
in the standard distribution (-e option.)

--
Bill Cole
[hidden email] or [hidden email]
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not For Hire (currently)
Reply | Threaded
Open this post in threaded view
|

Re: Using Postfix sendmail without having Postfix daemon running all the time?

Viktor Dukhovni
On Thu, Aug 06, 2020 at 03:32:11PM -0400, Bill Cole wrote:

> > A doable, but perhaps non-trivial, programming project would be to
> > start with Apple's Postfix sources, and port that functionality to
> > BSD and/or Linux.
>
> Not very doable, because the trigger was handled by launchd, Apple's
> systemd-like facility. The timed death of the Postfix master process is
> in the standard distribution (-e option.)

That's not a problem, the inotify bit does not *have to* to be part of
systemd or similar, it can be a separate queue monitoring process run by
systemd or similar.  That does leave the possibility of that process not
running, but the same can be true of a normal Postfix system.

--
    Viktor.