If your server is offline when a message is aimed at it, the sending system will not be able to do the transaction.
How this usually works (outside of using sendmail CLI to send a mail the old school way):
The sender's computer establishes wither a POP3 or IMAP connection with THEIR mail server, and they send the mail to that server. (Either using SMTP or IMAP, since this is an outgoing mail.) That server then accepts the message, and then tries to deliver it. Since your host (the destination) is offline, it cannot respond to the connection request. The sending system will optionally try again, before creating an automated response that it cannot deliver the mail, and dropping it in the sending user's inbox.
(When using sendmail CLI, no such broker is used-- the user's computer creates and sends the message itself. Depending on what command line switches are invoked, it may or may not alert to the system log that the recipient failed to accept the message.)
This assumes you are running your very own email server, and are not using a service like GMAIL.
When using a service like GMAIL, you have 3 methods of interacting with their server farm.
1) POP3/SMTP. This is the oldest, most legacy method. The client uses these two protocols to get incoming mail and send outgoing mail, respectively. Recent versions of these protocols allow for SSL encryption, which is one of the ways the password gets used.
2) IMAP. This is the newer methodology used, and uses different port number. Not all mail services support IMAP. It has better encryption support (as in, the transport is encrypted, not the actual message bodies.) support, and keeps messages on the mail server. (POP3 deletes the messages from the email server's inbox when it successfully pulls the messages into your mail client.)
3) The web interface. (GMAIL default, etc.)
Thunderbird does types 1 and 2. It asks which set of protocols to use when you first set it up, and tries to look up what the public server names/IP/Ports are for common mail hosts (outlook, gmail, yahoo, and pals) when it notices you use an @hotmail,@outlook; @gmail; or @yahoo address, and fills in all the blanks for you. Otherwise, it EXPECTS YOU TO KNOW. In the past, you had to hunt this information down yourself.
Once set up, it works like any other mail client. (It has a decided eudora pro feeling to me.) You can then optionally set up actual message body encryption with Enigmail plugin.
Security wise, If the handshake is set up to use SSL encryption, it at least does not send credentials in clear-text. (Otherwise, especially with POP3 and SMTP, if that option is NOT set, the user and pass *ARE* sent in clear text!!) This is only marginally better than clear text though, because it is typically SSL 1.0, which is very much broken as an encryption cipher. The basic rule is not to consider email secure. End of discussion.
This is why message body encryption with something vastly more secure, like with a 4096 bit Elliptical Curve algo, (or stronger!) is important, especially in today's world. even if somebody gets your user/pass, they cannot easily get ahold of your encryption keys, because those are kept local inside your computer, and are (if you are smart) never transmitted over an unsecured channel, and are not stored in the email server in an unencrypted form. Even if somebody gains access to your email server though snooping your user and password, they cannot actually DO anything with your messages except download a copy of gibberish, or delete the message. They would need the encryption key (since Enigmail at least, uses digital signatures and authority trust checking, to verify both sender AND recipient) set to do anything else, like actually read your mail, or send adulterated messages as a man in the middle.