[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Mailutils+nullmailer: sender full name



On Tue, Oct 17, 2023 at 09:50:13PM +0200, Gertjan Klein wrote:
> Op 17-10-2023 om 20:40 schreef Greg Wooledge:
> > On my system, mailx points to bsd-mailx:
> 
> On Geert's as well. I wonder why. I installed nullmailer, and it
> automatically pulled in mailutils. I stayed with it because I don't know any
> better. You and Geert apparently decided on something different. May I ask
> why?

Hard to say.  This system has been upgraded many times, and the package
names involved have perhaps changed over time.  There's also this:

unicorn:~$ aptitude why bsd-mailx
i   abcde Recommends bsd-mailx

There are *lots* of packages like that, including exim4-base.  Chances
are pretty good that something will bring in bsd-mailx without a user
explicitly choosing it.

I can't say, at this point, whether I explicitly installed bsd-mailx or
one of its predecessor packages, or simply got it as a recommendation.


> I do appreciate it. If I switch to bsd-mailx I have something that should
> work. Although I'm concerned by the statement (on the Debian package page)
> that it doesn't speak SMTP. This is how I send the mail on to my internet
> provider with mailutils. I wouldn't know how else to do it.

The way Unix mail works is by dividing the workload between an MUA and
an MTA.

The MUA (Mail User Agent) provides the user interface.  It's the program
you use to send and/or read mail.  Examples include elm, pine, mutt, mailx,
Thunderbird, and so on.

The MTA (Mail Transport Agent) (or Transfer) is the back end.  It's the
part that does the actual deliveries, including sending and receiving
messages over the Internet.

A command-line MUA like mailx sends mail to the MTA by invoking the
/usr/sbin/sendmail (traditionally /usr/lib/sendmail) program, which is
a hook provided by the MTA.  The MUA composes the message, which is a
stream of lines of text, and sends it to /usr/sbin/sendmail on standard
input.

So, it's not *expected* that your MUA will speak SMTP directly.  That's
not its job.

In your setup, nullmailer is your MTA.  Here's its package description:

 Nullmailer is a replacement MTA for hosts, which relay to a fixed set of
 smart relays. It is designed to be simple to configure and especially
 useful on slave machines and in chroots.

There are some key words in there that you might not understand at first
glance.  "Relay" is the term used when an MTA sends a message along to
another MTA on another computer, usually using SMTP.  This is different
from when an MTA accepts a message directly from a MUA.  That's usually
called a "submission", and can use either SMTP or /usr/sbin/sendmail.

"Smart relay" or "smart host" is a term used to describe a machine
that acts as an SMTP relay for a group of computers, typically on a
local area network, but nowadays that's not as common as it used to be.
The implication is that the group of computers only know how to send
mail to the "smart relay" and nothing else.  The smart relay handles
the rest of the job, doing DNS lookups, retrying upon failures, and so on.

So, when you send a message using "mail" or "mailx",

 1) Mailx (MUA) composes the message for you (including the From: header).
 2) Mailx sends the message to nullmailer (MTA).
 3) Nullmailer relays it to its "smart host" (some other MTA).
 4) The smart host sends it along, either to the final destination MTA
    or to the next hop MTA.
 5) Eventually, the final destination MTA receives the message and
    delivers it to a local inbox.
 6) The recipient reads the inbox using their MUA.


> I've found the mailutils documentation impenetrable as well. More searching
> and trying ahead, I guess.

I skimmed parts of it.  It appears to read ~/.mailrc if it exists.
You could try putting commands in there and seeing what happens. Start
with something like

	set from="My Name <my@address.net>"

and test with deliveries that don't go outside of your controlled email
environment, if possible.


Reply to: