Post by Richard HectorYou're not using the -v option, which tells the MTA to be verbose.
Exim then spits out the SMTP session, while postfix captures it and
send you back an email.
Now that I put it like that, I understand it better myself - mailx
isn't putting itself in the background, but the MTA continues to work
asynchronously.
I didn't use the -v option because I didn't want a delivery status
report that heirloom-mailx seems to request as well. But just for the
test I will do it and then delete the report.
***@havoc:~$ mailx -v ***@proulx.com
Subject: test
test
.
EOT
Mail Delivery Status Report will be mailed to <rwp>.
***@havoc:~$
It is that "Mail Delivery Status Report will be mailed to <rwp>." that
I was avoiding. I get the test message to myself. And I get a
delivery status notification that the message was delivered. I didn't
want that last. Note that I am using Postfix. I don't know if Exim
implements the -v option the same way.
$ man sendmail (postfix's sendmail)
...
-v Send an email report of the first delivery attempt (Postfix
versions 2.1 and later). Mail delivery always happens in the
background. When multiple -v options are given, enable verbose
logging for debugging purposes.
If I am testing out mail and wanting to observe the SMTP handshake
then I recommend "swaks" (Swiss Army Knife SMTP, the all-purpose smtp
transaction tester). It is a useful tool.
swaks --to $(whoami)@$(hostname -f) --server localhost
=== Trying localhost:25...
=== Connected to localhost.
<- 220 havoc.proulx.com ESMTP Postfix (Debian/GNU)
-> EHLO havoc.proulx.com
<- 250-havoc.proulx.com
<- 250-PIPELINING
<- 250-SIZE 102400000
<- 250-VRFY
<- 250-ETRN
<- 250-STARTTLS
<- 250-ENHANCEDSTATUSCODES
<- 250-8BITMIME
<- 250 DSN
-> MAIL FROM:<***@havoc.proulx.com>
<- 250 2.1.0 Ok
-> RCPT TO:<***@proulx.com>
<- 250 2.1.5 Ok
-> DATA
<- 354 End data with <CR><LF>.<CR><LF>
-> Date: Thu, 29 May 2014 14:41:06 -0600
-> To: ***@proulx.com
-> From: ***@havoc.proulx.com
-> Subject: test Thu, 29 May 2014 14:41:06 -0600
-> X-Mailer: swaks v20130209.0 jetmore.org/john/code/swaks/
->
-> This is a test mailing
->
-> .
<- 250 2.0.0 Ok: queued as E6DAF2DC05
-> QUIT
<- 221 2.0.0 Bye
=== Connection closed with remote host.
And there are many other options for customizing exactly what type of
testing you are wanting to do. This tool is for SMTP testing and
doesn't use /usr/sbin/sendmail however.
Post by Richard HectorNow that I put it like that, I understand it better myself - mailx
isn't putting itself in the background, but the MTA continues to work
asynchronously.
The mailx command is sending the message through /usr/sbin/sendmail
(which you might remember as /usr/lib/sendmail in the old days) and
then sendmail is sending the mail. The name "/usr/sbin/sendmail" in
this case will be an alternative and be either Postfix or Exim or
Sendmail or Nullmailer or other MTA as installed and configured by the
alternatives. All of the MTA alternatives in Debian should work fine
as an alternative /usr/sbin/sendmail interface.
By default /usr/sbin/sendmail will drop the message into the queue and
then notify the running daemon that a new message is available for
transmission and will return to the caller very quickly. Delivery
will occur in the background through the MTA daemon. So mailx itself
is never in the background. But email is designed to be a store and
forward background delivery and it occurs in the background on a best
effort basis. I say best effort because if the disk is full or if the
cpu load is too high or the network offline then delivery will be
delayed until resources are available for it to be completed or until
it times out.
As to why your command prompt isn't being emitted after the task is
done that seems very strange to me. Definitely not normal. As you
can see from my examples it works fine for me. Please let us know
what you find is the problem.
Bob