# specify recipient # edit text # send out
The order of the first 2 items can vary, the last is always the last.
A matter of taste: Specifying recipient (or generally any header information) can happen before or after you edit your text.
Some prefer to enter header info in the compose menu, other prefer to change them inside the editor along with the content/ body. In the latter case, you can edit even non-standard headers.
to fill: details for doing both.
Headers can be specified manually in the compose menu or automatically, see /Headers.
When you enter recipients, you either use mutt's internal address management system called /Aliases. or you can use external databases and commands to store and retrieve addressbooks. See QueryCommand and /UseLDAP for more.
Before you send a message, you must provide the recipient, a subject and the content. There are 2 ways to provide content:
- a previously edited txt-file as STDIN on the cmd-line.
- interactively typed in an editor invoked by mutt.
to fill: details for doing both.
This page will (at least for now) discuss possible options in the area of sending mail and only sending mail. Big MTAs configuration such as exim, postfix, qmail, etc, will not be treated here. Lets get started!
Mutt, by itself, cannot send mail (new in 1.5.14: it can). Unlike programs like Thunderbird or Outlook, there is no built-in capability to do anything outside of your machine. To the more technically inclined, mutt does not speak SMTP (see MailConcept). But that is where the MSA comes in.
MSA Stands for Mail Sending Agent, and it does exactly what it says: send mail. Do not get this confused with MTA (Mail Transfer Agent) - MTAs both send and receive; or MUA (Mail User Agent) - an email authoring program (which may also be a MSA, such as Thunderbird or Outlook). When you send an email via mutt, mutt hands the message to the MSA, which then delivers the mail to your ISP's mail server. Most MSAs are very simple to configure and install, and ususally need little or no tweaking to the .muttrc.
See list of LightSMTPagents (MSAs) that you may want to try, esmtp and msmtp are popular. Check them _all_ out, and give feedback (here) how well it works!
Mutt interaction with the local mail server
Many MUAs provide facilities to comunicate directly with a remote server, so that you don't need to have installed and running a local server on the sending host. In those cases the mua comunicates directly with a mail server (using the SMTP/ESMTP protocol), when you specify to do it (e.g. when you push a button like "send all").
Mutt doesn't provide (unless patched) such a facility, but it has to generate a new mailer instance that will act as SMTP client in place of mutt. (new in 1.5.14: it has).
The message generated by mutt is passed via stdin to a new instance of the mailer program (a mailer program such as sendmail, exim or postfix act either as server and as client, although they're generally referred as servers). This new instance will act as a SMTP client, and will connect to the local server on port TCP 25 and will transmit this message to the local server.
At this point the client process will terminate, and its return code will be delivered to mutt.
Now the message has been transmitted to the local server, and it's server duty to process the message and eventually transmit it to another (remote) server.
In this model the mua hasn't to know nothing about the SMTP protocol, while it has to know (hopefully very well, like mutt) all about the formatting of the message itself.
Setting the SMTP client to be used by mutt
You can define the program mutt will start for delivering the new composed messages setting the sendmail variable.
A common setting is:
set sendmail="/usr/bin/sendmail -oi -oem" # how to deliver mail
The mail server (in this case sendmail) will receive the message in input, and will parse it. In case of a malformed message, it will send and error message to the user to whom belongs the mua trasmitting the message (e.g. <tt>user@…</tt>), and it will exit with a non zero exit code: the -oem flag forces the returning of a non zero exit code even in the case the error message has been successfully sent to the local server. The -oi tells the sendmail instance not to terminate the incoming message when is encountered a dot on a line by itself, but will read instead all the messages up to the EOF. Both options seem to be meaningful.
Please note that even if you're not using sendmail on your system this command might work as well, since other mailers (exim, postfix) mimic the sendmail command line interface, and their installation creates a simbolic link named "/usr/bin/sendmail" pointing to their correspondent mailer binary.