Plain text e-mail notifications

(jon r) #1

Dear community,

as I’ve just garbled (Does such a word exist in the English language?) with a forwarded notification e-mail that has been full of HTML.
As I’m not a friend of HTML e-mail at all, I’d like to have all notification mails in plain text.

Would it make sense to try to provide a little plugin? Or could someone of the core team provide a little hack as a setting?

Just curious; greetings from Berlin.

Simplified HTML emails
(Jeff Atwood) #2

All emails have a plain text payload as well as HTML since they are Markdown. So why not just select that payload?

(Kane York) #3

Here’s what your plain text should look like:

Content-Type: text/plain;
Content-Transfer-Encoding: 7bit

@riking I can't/don't want to move to a Docker install because I have other websites on the same Nginx instance and I don't have enough money to have a seperate server.

Posted by archon432 on 03/19/2014

*Previous Replies*

Can you consider moving to a Docker install?

Posted by riking on 03/18/2014

Same issue, Ubuntu 13.10, DigitalOcean.

Posted by archon432 on 03/18/2014


Everytime I restart the server, I'm getting this mail via cron:
> env: [/home/discourse/.rvm/bin/rvm/bootup_bundle,: No such file or directory

This is annoying. But discourse is starting just fine after reboots. I've used the following commands twice to be sure:

    rvm wrapper $(rvm current) bootup bluepill
    rvm wrapper $(rvm current) bootup bundle

My crontab entry is:

    @reboot RUBY_GC_MALLOC_LIMIT=90000000 RAILS_ROOT=/var/www/discourse RAILS_ENV=production NUM_WEBS=2 /home/discourse/.rvm/bin/bootup_bluepill --no-privileged -c ~/.bluepill load /var/www/discourse/config/discourse.pill

What's more ridiculous is, if I execute that manually the error is not shown.

What might be the problem? I'm using **Discourse** on **Ubuntu 12.04 LTS (32 bit)** with **ruby-2.0.0-p353**

Posted by mugli on 12/31/2013

To respond, reply to this email or visit in your browser.

To unsubscribe from these emails, visit your [user preferences](
Content-Type: text/html;
Content-Transfer-Encoding: quoted-printable


(jon r) #4

Thanks for following up.

The thing is I’m against HTML at all on an ideologic level. So I’d prefer having a plain text mail interface, i.e. for the notification and mailing list modes, in general.

So the question would be, if I could deactivate the multipart generation via the settings menu.

(Jeff Atwood) #5

No, that is not currently possible. You could submit a pull request with a setting to enable it if you like.

(jon r) #6

Merci. Let me see if I find a way how to do it.

(Michael Downey) #7

Hi @almereyda. Did you ever take a look at this? Quite a few of our users would probably take advantage of this profile setting if it were available. :slight_smile:

(jon r) #8

Not up until now. Resides somewhere in the backlog blockchain …

Update: I’ve encountered a lovely Plain Text E-Mail from Open Knowledge Forums, where even the links would be nicely extracted and put at the bottom. I suppose there’s a certain commit that makes this possible, so we can consider it Best Practice Plain Text support.

Clients that don’t support multipart are either way to be abandoned. So it is already upon the users to decide - but not within Discourse, but their local email client.

Content-Type: text/plain;
Content-Transfer-Encoding: 7bit

A brief summary of [Open Knowledge Forums][1] since we last saw you on 11-27-2014.

### Popular posts

[Can we resurrect][2]

 Great to hear from you and let's get this back up. 

First, some context: the site was set up by Phillipe Piagnol who then transferred it to Open Knowledge and specifically Open Knowledge Labs about a year ago. 

Resources: - site is down right now but was up last Autumn and you can check it on the Way Back Machine

Codebases: - 4 github repos associated
Drive folder with documentation
This is the associated general website: (see Resources section especially which contains quite a bit of documentation)

For my part, I will work to find out which server this is running on and to get you access to that.

[Resolutions for Open Economics][3]

 Hi everyone, 

I have previously tried to awake this group by creating our wiki page, our own IRC channel, and unfortunately, it seems that the people that were involved with this WG have moved on. Therefore, since there is no one else trying to work on this WG anymore, I'd like to know if is possible and if it sounds plausible if I take over the Leader position of Open Economics. I haven't thought about it through in terms of plans and actions. Right now, I believe the priority is to reestablish its work flow and get more people involved. If that is okay, I'd like to know what needs to be done to make it happen.  

I also have emailed the system admin email to request 3 things. My intentions were to bring back the people involved, but it failed. However, I still need them if I end up as the leader of this WG. In case anyone can help me solve them, please let me know. My needs are: 

Problem #1: Email issue 
Request:  Is it working? I recently emailed it to report a Portuguese faile...


This digest is sent as a courtesy notification from [Open Knowledge Forums][1] when we haven't seen you in a while. To unsubscribe [click here][4].


Should we still keept the plain text only option in the backlog?

(jon r) #9

Being logged in @codinghorror I cannot edit my post above any further?
Visual feedback why? as a suggestion.

So in Log in to Mandrill Mandrill has this

  • Generate Plain-Text from HTML emails

but there’s no option to strip the HTML part. Maybe we should ask them about this?

(Jeff Atwood) #10

There is a default time limit on editing your posts, we have been moving it down, I think it is currently at 3 or 6 months two months.

(Michael Downey) #11

The current (default) value for my site setting of post edit time limit is 86400 minutes (60 days). Is that what you’re referring to?

(Michael Downey) #12

Isn’t this Mandrill option more for those people who don’t send plain text equivalent alongside their HTML emails for regression when needed?

(Darren) #13

Did anything further happen with this? The forum I starting has quite a few people who would prefer plain text email only if it could be made an option on their profile settings.

(Rafael dos Santos Silva) #14

We still send both HTML and Text parts, just configure your mail client to prefer one or another.

(Eli the Bearded) #15

I just read the “plain” text email part and ignore the HTML part. (But that “plain” text is actually markdown.) I know people more curmudgeonly than myself who don’t want the HTML part at all, and they use filters at delivery time to remove the HTML parts. This has the advantage of working for every sender on the Internet, not just a few Discourse sites.

The best such filter I know of is Mime Defang. You are going to be on your own setting it up, however. That sort of thing requires local knowledge of how your email is processed at delivery time.

Example local knowledge issue: This will break DKIM signatures, so if you are verifying them, you need to do that first.

(Leo McArdle) #16

This is a feature I’m planning to implement as a plugin within the next month or so.

If you want you can follow along with progress here:

Or watch this topic, where I’ll post when it’s done:

(Eli the Bearded) #17

That topic sounds completely different, so I have couple of questions.

My understanding was that plain text + html MIME multipart is a native Rails feature.

If you used a template for which there was only a text version, wouldn’t Rails do the sensible thing and only send text mail? If so, issue 51 (simplified notification mails) seems like a trivial application of issue 50 (offer a selection of templates).

(Leo McArdle) #18

Different, but I wouldn’t say completely :wink:

I mentioned it here because I’ve discovered that often when users request plain text emails what they’re actually requesting is simple emails - they don’t mind a jot if there’s a <b> here and a <p> there, they just don’t want big images and bold colours and all that nonsense distracting them.

I’m not actually sure about that one, I’ll probably find out as I work on issue 51.

Yep, 51 would be the functional implementation. 50 is adding the appropriate hooks to Discourse core.