Bug 2530756

The esmtp package ships /usr/bin/esmtp-wrapper to queue mail and then invokes the real esmtp binary. This causes two problems for callers that rely on esmtp's exit code or stderr to determine whether a specific message was delivered:

1. esmtp-wrapper itself always exits before the real esmtp call has happened, so its own exit code says nothing about whether the mail was actually delivered. The real esmtp is only invoked later, in a separate, detached process, once the queue is flushed.

2. When esmtp is eventually invoked to flush the queue, it may send several queued messages in one go. Any errors on stderr at that point come from the whole queue flush, not necessarily from the message that triggered it. This means a caller can see errors unrelated to their own message, or conversely see no error even though their message failed, since success/failure is reported per flush rather than per message.

Taken together, esmtp-wrapper does not provide a way to reliably determine per-message delivery success or failure.

Debian and Ubuntu do not appear to install this wrapper.

We'd like Fedora to reconsider shipping esmtp-wrapper, given how unreliable its error reporting is.

Reproducible: Always

Steps to Reproduce:
1. Configure a program to send mail via /usr/bin/esmtp-wrapper, e.g. as its sendmail-compatible MTA
2. Send a mail message that should fail and check the exit code
3.
Actual Results:
The exit code from esmtp-wrapper does not reflect whether the message was actually delivered.

Expected Results:
Either esmtp-wrapper should reflect the real esmtp exit code and error output for the specific message just submitted or it should not be used as a default sendmail replacement.