We’re using discourse as a mailing list, and it appears that forwarded emails do not show up in the posts. If you look at the source of the email you can see there is alot of content that is not included. Ive tried a few things including removing this line:
---------- Forwarded message ----------
which did not work, and then removing these lines:
---------- Forwarded message ----------
From: Foo Bar <foobar@bar.org>
Date: Mon, Dec 15, 2014 at 10:39 AM
Subject: A gift from one Foo to the next! Instructions and sample gift [staff]
To: barfoo@bar.org
which apparently DOES work. But of course this is a fairly crucial bit of info.
I’d love to hear how others handle this scenario and how you instruct your users to prepare their emails so the whole message arrives? Thanks!
I swear we’re working on the same forum Another thread today consisted of people repeatedly testing the forward functionality, and not being able to do so. Even copying and pasting without quoting supposedly didn’t work.
Awesome! So I am not alone. Let’s figure this out together.
Here is how I guide my community on dealing with this right now - still not sure it’s the best way but it seems closest to the reality:
Forwarded emails are truncated. As time permits, to quote a message you are forwarding, please change the subject line to make it as meaningful as possible and remove the message headers from the message you are forwarding and replace with a brief intro of the message you are forwarding, from whom, and why you are forwarding it. The headers to remove look like this:
<code>---------- Forwarded message ----------
From: foo <foo@bar.org>
Date: Mon, Dec 15, 2014 at 10:39 AM
Subject: A gift from one Foo to the next! Instructions and sample gift
To: bar@bar.org</code>
Quoted text is also truncated. Remember, Discourse is trying to help us to have organized and pleasurable to follow discussion topics. If you wish to refer specifically to a few lines of what someone has written before you, quote it by placing it on its own line after >.
Definitely think we should help flesh out some of the pain points with email that we have currently - maybe over the new year period I’ll get around to putting some stuff down, but in the meantime the major things are already reported on here I think
I think the forwarding issue could be aided by not truncating if it can see it’s a forwarded message, e.g. if it sees Fwd in the subject, it strips that out of the subject, but retains the email in the post.
If it sees Forwarded Message (and variations of), it doesn’t strip that part out of the post.
Wouldn’t this vary by language? Seems like an OK fix for English though, but not sure the GitHub email parsing library we use allows bypassing stuff like that (stripping previous replies).
I don’t think inline replies is the same as a forwarded email at all, they are totally different scenarios. And forwarding is odd, nobody would forward an email to github.
Forwarding an email may be odd for github, but not odd at all for our community using discourse. Sometimes people just want to forward an email with a few lines at the top to discuss it.
I’d rather have it go through (perhaps munging email addresses) and then clean it up later rather than having it just truncated silently, leaving everybody wondering what’s going on.
@techAPJ I will send you some sample forwarded emails. The test suite snippet you shared is interesting. Can you confirm that in that snippet, on line 83…
assert_equal "--\nHey there, this is my signature\n", reply.fragments[6].to_s
… that this means that it assumes that everything after two dashes at the start of a line is the signature and therefore should be truncated? This is what I think is causing problems for people on my discourse especially with forwarded emails.
Right but the email library we are using this for is from GitHub, they use it internally, so it would be highly unlikely that it handles (or expects) forwarded emails at all.
Forwarded email conversations may have one indentation of quoting. However, multiple forwards can turn into a nightmarish situation. How about including an option for “max indent level for email replies” with a default value of 1. This way, if we want to include a forwarded message or two, we can do that.
How difficult would that be to implement? Wouldn’t the parser simply need to look for the leading “>” character in plain text emails and just decide whether or not to include that?
Additionally, since multiple levels of plain text forwarded messages just have more “>” “>>” “>>>” characters. Couldn’t you just include them and format them to collapse/expand within Discourse?
The handling of forwarded email into discourse is certainly a frustrating issue.
I just had an oddball idea: what we really need is another special email address that takes the forwarded email and automagically attaches it as a PDF, then forwards it on with original headers to the forum. That way legibility is retained at least. Or an admin setting in discourse to convert to PDF and attach everything that would normally be truncated.
But @mochabcha the real issue is that discourse is using a library intended for github, which has a different purpose than ours. Not sure when/if that will be resolved.
In the meantime it’s about user training. I have been telling my team to edit what they forward or to post forwarded messages directly on the forum. In the end, arguably, this leads to better discussions anyway.
aside: I am loving the newly discovered (by me) collapsible text syntax. It would be nice to see forwarded email text presented like this instead of simply being truncated. But it will still have legibility problems because of the github parser. Ah well.
Typing in this:
<details><summary>Click this to view the longer transcript</summary>This part could be could be a huge long text</details>
produces this:
Click this to view the longer transcriptThis part could be could be a huge long text
I see what you mean. I’m more than likely going to make a video or series of GIFs that clearly explain posting rules for the forum. I would however, and my apologies but this is unrelated, like to know how to customize the reply and error emails. I’m going to look that up. I do believe the process of evolving the digital conversation is going to hinge on boundary setting and proper education.
I’ve spent the day trying to resolve what works (and what doesn’t) for inline replies. Is there somewhere I should post email examples that one would think should work but don’t?
Apologies for more lack of Ruby knowledge, but can you let me know what version of the email_reply_parser is currently being used by Discourse? Is it the relatively recent version of Github’s or @sam’s original fork?
My albeit brief reading of the Github parser suggests it should be working better than the observable Discourse behaviour, but i don’t have any sort of test harness to throw failing emails at.
Does that <details><summary> trick (which I never knew before as well) also work the same on emails, though? As email standards suck, I doubt it.
I don’t like the attachment idea either, as attachments should just not exist in emails. It’s wrong in so many levels and I believe the discourse team also relinquishes it.
Probably a better idea would be simply showing the full body of email on site:
But even that, how much is it really needed? How many cases for a real problem of this really are there? Aren’t people slowly adjusting and learning how to properly use it? Can’t mods just fix the cases that slip by?
I’ve been slowly moving our internal teams over from Basecamp to private categories on Discourse and email forwarding will help bridge the gap when people rely on email or when a third party communicates with us.
I’ve been reading other topics here about this issue, and it seems that the solutions proposed are fairly complex.
All that my users were expecting to happen when they send an email to an email address associated with a category is that body of the forwarded email would be preserved. (It’s currently cut.) For our purposes it would be fine if it just created one post with the forwarded content inside a blockquote.