You can adjust the display of messages via the ~/.config/geary/user-message.css file.  Take a look at theming/message-viewer.css or use the inspector (launch geary with -i and open via right click) to see the what elements to target in CSS.  The contents of each email are in a div.body.  Plain text emails are also in a div.plaintext, so I have a rule
    .plaintext {
        font-family: monospace;
    }
in my user-message.css.

That's nice, thanks for mentioning! 

But it does not solve my second problem. Other clients, such as thunderbird or evolution, filter html-only mails to force plain text messages (if filtering is enabled). It is useful when you do not want to see ugly colored html mails from ebay, amazon or your internet provider.

I personally hate html mails and like to read my mails in plain text. But I'm afraid such a (bugfree) filtering feature would be hard to implement. For now I'm quite happy with your CSS monospace font solution.

Like all things email, there's a lot of issues here.  Some of what follows is just me thinking through all this.

In the case of bug #714306, there's the question of how to display pure plaintext emails (in that case, flowed plaintext).  Some people want them monospaced, some do not.  If we offer the choice (beyond Robert's way, above), it should probably be a Preference setting, although we try hard to avoid overpopulating Preferences with a lot of fine-detailed options.  I wonder if it could be like how we do image handling: "Show this email monospaced" and "Show all email from this sender monospaced" in the message drop-down menu.  I wouldn't use a Preferences option because, for the most part, I like variable width fonts, but some times (for example, bug reports) monospace is useful.

This reporter is asking for the ability to read all mail as plain text, even if it has an HTML component (bug #730680).  This could be a Preferences option as well, although I imagine some people might want to switch on-the-fly depending on what kind of email they're viewing (which is what the reporter in that ticket is asking for).  But choosing to read an email in plaintext doesn't imply a monospaced font.

Converting HTML into plaintext isn't ticketed yet (I think), so I've converted this ticket into that rather than mark it a duplicate of the others I've mentioned.

Finally, there's the composer side of things.  If the user wants to view plaintext in monospace, presumably they want to compose replies (and perhaps all email) in monospace font, although I'm not certain that both are a lock.  Perhaps the composer needs to be "smart" when replying.

I suspect we're stuck with having two Preferences: one to select a font family for plaintext and one to override HTML mail.  Converting HTML -> plaintext could be added later (and keyed to the second Pref option).  The composer's font choice could follow the first Pref option or use some heuristics to determine which to use.

I would really like to have an option to enable plain text view for all e-mails. Firstly, it improves privacy and security. Companies who send you an e-mail can track when you read the e-mail if pictures etc. are loaded from their server.
Secondly, if geary adds support for gpg mail encryption, it has to support plain text e-mail anyway.

(In reply to comment #4)
> I would really like to have an option to enable plain text view for all
> e-mails. Firstly, it improves privacy and security. Companies who send you an
> e-mail can track when you read the e-mail if pictures etc. are loaded from
> their server.

Geary blocks all remote resources by default, although you can allow them on a per-email or per-sender basis.  As long as you don't do this, you're just as untrackable now as you would be reading plain-text emails.

> Secondly, if geary adds support for gpg mail encryption, it has to support
> plain text e-mail anyway.

Geary does support plain-text emails.  My completely baseless guess is that anyone who cares to send encrypted or signed email will already be sending plain text.  This issue is about converting an HTML email into a plain text one, and bug #730680 is about allowing you to switch formats when the sender supplies both.

This won't ever make it as a standard enabled shipped feature, but is ideal for a plugin: https://gitlab.gnome.org/GNOME/geary/issues/155