Option A signs the public key rather than the message. As the goal is to authenticate the message, the signature over the public key is useless for this purpose.

Option B signs the message. It however has the disadvantage that it is possible for an adversary to guess the message and verify the correctness of the guess. As such, it doesn't provide full confidentiality. It may also be vulnerable against oracle attacks unless a IND_CCA2 secure cipher is used; it could be that the receiver leaks information when trying to decrypt *unauthenticated ciphertext*.

Option C signs the encrypted ciphertext. It doesn't provide any authenticity of the message for email encryption because somebody can simply strip off and replace the signature. It would only provide authenticity if Bob only expects signatures of Alice, and disregards any other public keys that can be used to verify the message. This is however commonly not the case for person-to-person mail encryption.

Option D is clearly some mumbo jumbo to have a fourth option. As the operation $K_{A}^{+1}(M)$ doesn't make any kind of sense even with regards to the notation, it is probably best to ignore it. 

---

Option B is an *encrypt-and-sign* scheme, option C is an *encrypt-then-sign scheme*. 

Generally we use a (missing) *sign-then-encrypt* scheme where we send $E_{K_B}(M, \text{Sign}_{K_{A}^{-1}}(M))$. Obviously *sign-then-encrypt* should be used with care as well; it does require a IND_CCA2 secure cipher just like option B. Note that I've left out some kind of encoding function to merge the message with the signature.

Now that you know the terms you can look up Q/A and discussions such as the one [here](https://crypto.stackexchange.com/q/5458/1172). Note that we often need to include additional information in the scheme for it to be secure in a practical sense; protocol design is however a separate topic.

---

EDIT: Come to think of it, it is also possible to replace the signature for option B, so that would make option C *marginally* better.