[Feature request] composition in plain text

[mbolivar]

I'd like to use Nylas for reading and responding to patch emails on mailing lists. These often have strict requirements that message bodies be plain text. I don't see a way to set this up in Nylas.

[grinich]

This currently isn't supported, as the Nylas Platform APIs only support HTML for sending. https://nylas.com/docs/platform/#sending

Note that a plain text version is included, but you can't compose in plain text.

[mbolivar]

Thanks for getting back to me.

FWIW, this is a deal-breaker for me personally, but I wish you the best of luck nonetheless. Fighting the good fight on the desktop email front is something that nobody seems willing to do besides y'all these days.

[screendriver]

+1

Same here. I need to send mails in plain text.

[wget]

@grinich Do you have any solution used at Nylas to vote for feature requests like this one?
Like said in the aforementioned related bug I opened, having this feature is a deal-breaker/requirement on my side to adopt completely Nylas N1.

[grinich]

Just to be clear, N1 will send a text/plain MIME part for any message that goes out. We built the sync engine APIs to only support HTML for simplicity, but it "down converts" the HTML to a text version using the html2text Python package. You can see where we do it here.

We actually haven't found any issues with this and the conversion does pretty much what you would expect (e.g. turning blockquotes into > sections). For mail servers that don't use HTML, they can always grab the plain text section included in the raw MIME body.

Can you give us a bit more info on what this is stopping you from doing, or why it's a dealbreaker? Is the html2plain causing weird rendering somewhere? Is a mail server or email list rejecting your messages? If so, which one and what are they running? etc. etc. Thanks! 😄

[wget]

I know Nylas is sending the email in both version. This is what I directly checked when I tested this client for the first time ;-)

I asked a few open source projects I'm contributing to. At The Document Foundation (LibreOffice), there isn't any technical requirement anymore. While mailman had issues with HTML mails, this was long ages ago. Now, the requirement for text-only mail is only a social requirement, like the netiquette is. Mailman seems to be able to take only the text-only version as there isn't any traces of HTML in the public archives.

While I couldn't find the text-only requirement at The Document Foundation, some FOSS projects still require it. That article summarizes quite well the situation wrt. the email netiquette.
This means N1 will likely never be used by such hackers and it's a pity.

Is that really so difficult to put a condition on the Nylas platform? I assume this would require the client to send each time to the Nylas platform in which version he wants the email to be sent.

[grinich]

It gets more complicated since the API for fetching objects (i.e. /messages) returns a single body object with an HTML string. This was done so developers can just insert the body into a sandboxed iframe/webview and display the contents. If we add sending plain text, we likely need to also add a plain text body in a response that may not include HTML. And then developers will need to write two functions for rendering messages and figure out what text elements like \n need to get replaced with HTML characters like <br>. This sounds doable but there are dozens of such cases and this means (1) everyone needs to do it, and (2) everyone will do it different. The problem quickly becomes fractal and adds a bunch of edge cases to a system that we have worked really hard to make as consistent and simple as possible.

That OpenStack wiki says:

If you do send HTML email (please don't), at least configure your client to include a plain text alternative as an attachment.

We do this! :)

N1 isn't really a replacement for Gnus or Mutt. Just look at the specs: the app weighs in over 200 MB, includes both Chromium and NodeJS, and uses a ton of memory when running. We did this because our focus is (1) extensibility via latest JavaScript, and (2) a modern end user experience comparable with Gmail or Outlook. I don't disagree with you that plain text sending is a necessary feature in these communities. It's just not our focus or N1's raison d'etre.

[cleverdevil]

Sigh.

Good luck competing as a consumer-focused email client against Airmail, Polymail, GMail, Outlook, Apple Mail, Spark, etc.

It saddens me to see Nylas completely squandering this opportunity to corner the developer/geek market. Built-in plain-text email composition, catering to members of open source communities (like your own, by the way), would be massively popular amongst geek influencers. Built in GPG support, with slick integration to Keybase, would give you some major cred with us, too. Make it possible for us to compose emails in Markdown for our plain text alternative, with the generated HTML being there for recipients who wish to view their email in HTML. Give us the capability to prefer viewing plain-text alternatives in emails, or at least to toggle between HTML and plain text.

Competing in a crowded space means that you need differentiation. Being open source, but not catering to the very people (developers) you're asking to join your community means that you're not leveraging your one key differentiator.

[cleverdevil]

Oh, and when I say "give us," I also mean "let us give you." Because, unlike consumer-oriented users, we can actually do that ;)

[molstrangler]

+1

[roramirez]

+1

[vician]

+1

[3v1n0]

This is really somewhat needed.

It's quite hard to work in mailing lists (especially the ones handled by mailman) in the open source world, without this feature.

[roramirez]

That is a good point @3v1n0. With this feature may interest some hackers to contributing with the project ;)

[cleverdevil]

I've abandoned N1 because of this issue. Was working on some themes and plugins, but decided that Nylas doesn't value the highly technical user, in spite of their open source roots. Back to mutt for daily use.

[mbolivar]

As the person that started this mess to begin with, I just thought I'd leave a note here that I've moved to a combination of notmuch, emacs, offlineimap, and msmtp to solve this problem for me. I version control the configuration files using Git, and have a writeup of how they all fit together in the same repository here:

https://github.com/mbolivar/dotfiles/blob/master/local-email-setup.txt

Hope this helps someone who's looking for a solution and shares my predilections :).

[alainsanguinetti]

I also would like to see this feature.
Not only for practical reasons but also for ideological reasons. Mailing is so big nowadays that the environmental footprint is something to consider. Imposing HTML increase this footprint, doing both HTML and text is even worse I guess in that respect.
As far as the technical point of view is concerned, I think you can pass a body element containing a verbatim element containing the corpus of the text email for fetching.

[owain68]

+1
It really is a mandatory requirement for developers participating on mailing lists.

[seekr]

+1

[tobias-dev]

+1
I'd like to see this feature too and the issue re-opened. It's a basic and important option that should be in every email client from my point of view.

[CatalinMustata]

+1

[rasmuse]

+1

[franzos]

+1
I actually couldn't believe it does not support plaintext.

[remexre]

The only technical problem here is the /messages endpoint, right? Why not make it so that by default, plain text messages get escaped to HTML and stuck in a <pre> on the /messages endpoint, then add a /messages/plain endpoint that returns plain text messages as plain text, and puts HTML messages through html2text (mentioned above that it's already used, so not even adding a dependency).

With me, certain mail clients assume that encrypted mail is always plain text, and so display full HTML tags for the decrypted mail, so I'd want to always use plain text for GPG'd mail

[adeel]

+1

[ask]

+1 for sure, this is insane. Even just the option to strip the HTML part of the multipart message when sending would suffice.

Is there any way to do this with a plugin? Surely it must be possible to hook into and rewrite message headers and body?

[koenpunt]

The sending API supports "raw MIME", so using this should make it possible to send plain text email I think?

[koenpunt]

This works, and arrives as-is:

# message.txt
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Subject: Test Plain Text
From: Koen <example@gmail.com>
To: Koen <koen@example.com>

My message body

curl https://accesstoken@api.nylas.com/send -H 'Content-Type:message/rfc822' \
  --data-binary @message.txt

[dahacouk]

Plain text!

[captn3m0]

Since the conversion works over the nylas APIs, if you are directly connecting over SMTP, this doesn't seem to be working. Only the text/html part gets sent.