When you have finished preparing a message, send it. Normally, just type send at the S> prompt. You can vary that procedure in some ways.
Normally, to send the message, type send or just s at the S> prompt. In response you see a list of addresses with the message Queued, meaning they went out to the sendmail program to be mailed. The send command also ends the send procedure, and you are returned to the MM> prompt (or R> if that's where you started).
S>s fb2... Queued. mm33... Queued. hk12... Queued. MM>
The normal output, the line address... Queued repeated for each address, is controlled by the variable send-verbose, normally set to yes. If you change it to no, you get a shorter message, just Sending... Done. To change, type set send-verbose no. If you are sending to a large mailing list, you might want to change the variable just for the one mailing, to reduce the display. If you want to change the variable indefinitely, save the change with the save-init command. Here the variable is changed but not saved:
S>set send-verbose no S>s Sending... Done MM>
After you give the Send Mode send command, MM passes the outgoing message to another program called sendmail. Normally, you are not aware of sendmail, because of the setting of two variables. The first, sendmail-background is normally set to yes, and makes sendmail run in the background, so you don't have to wait for it to finish, but can go on to something else. The second variable, sendmail-verbose, is normally set to no and suppresses messages from sendmail. There is not much reason to change either of these variables, unless you want to track sendmail's operation for some reason.
You can set a variable called default-send-command to define a command to be done if you only press the return key at the S> prompt. Normally the variable is set to nothing, so just pressing the return key with no command does nothing, and you get another S> prompt:
You can define default-send-command to any valid command, so that command will be done. For example, you could type define default-send-command send, and then just pressing the return key would send your mail.
MM>set default-send-command send MM>save-init
S>[return] fb2... Queued. mm33... Queued. hk12... Queued. MM>
The problem is that now you could press return by mistake, and in doing so send mail that is not ready yet. A command like display would be safer since no harm would be done by accidental use. To set the variable back to nothing, just type set default-send-command with nothing else. If you make any change, type save-init to save it.
If your mail cannot be delivered, it will generally be returned to you, if the mail network can find a path back to you (mail to other networks may occasionally get totally lost). The returned mail is known as a bounce message, and the mail system includes one or more lines in the bounce message telling you (cryptically at times) why the mail bounced.
In some cases, sendmail determines the host part or local username is bad immediately and returns the message almost as soon as you send it. Where mail has to be relayed down a chain of nodes or hosts, typical of mail to other networks or within BITNET, it may take a little longer for an error to be detected, but return within an hour is still typical.
Sometimes when the local sendmail detects an error right away, MM will report failure at the MM prompt. In the example below, the message abcdef... User unknown appeared on screen a few seconds after the MM> prompt. You still get a bounce message, too.
S>s abcdef... Queued MM>abcdef... User unknown